[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X08CGGEXHEGGYM5D1K7B2P":3,"skill-same:01M6X08CGGEXHEGGYM5D1K7B2P":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6X08CGGEXHEGGYM5D1K7B2P","software-modularization",null,"Design and evaluate module and package boundaries for maintainability, low coupling, and AI agent context efficiency.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fengineering\u002Fsoftware-modularization\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"software","software modularization","design","ai agent","package","engineering","work","context","wed","efficiency","maintainability","module","coupling","v1","for","evaluate","2026-11-10 10:12:30",false,"---\nname: software-modularization\ndescription: >\n  Design and evaluate module and package boundaries for maintainability,\n  low coupling, and AI agent context efficiency.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-software-modularization\n    version: \"1.0.0\"\n    created: 2026-04-08T00:00:00Z\n    category: engineering\n---\n\n# Software Modularization\n\n## Intro\n\nModularization is the practice of decomposing software into units with\nclear boundaries, stable interfaces, and minimal cross-cutting dependencies.\nGood module design is what makes a codebase navigable by humans — and\nloadable by AI agents without blowing the context window.\n\n## Overview\n\n### The two goals\n\nModularization serves two audiences who want the same thing for different\nreasons:\n\n- **Humans** — small modules are understandable, testable, and deployable\n  independently. The cognitive load of a 500-line module is manageable;\n  a 50,000-line monolith is not.\n- **AI agents** — the agent's context window is finite. A module that an\n  agent can fully load and reason about without truncation produces better\n  results than one that must be partially loaded. Target modules that fit\n  in ~8,000 tokens of context (roughly 500–800 lines of code + docs).\n\n### Module boundary heuristics\n\nUse these signals to find the right cut:\n\n**High cohesion** — everything in the module exists for one reason.\nIf you need two sentences to describe what the module does, it probably\ndoes two things.\n\n**Low coupling** — the module's public API is small and stable. Count\nthe imports from other internal modules: more than 5–7 direct internal\ndependencies is a warning sign.\n\n**Independent deployability** — could you version, test, and deploy this\nmodule on its own? If yes, the boundary is probably right. If it always\nrequires co-deployment with other modules, the boundary may be wrong.\n\n**Domain alignment** — module boundaries should follow business domain\nconcepts, not technical layers. `user-auth` is a better boundary than\n`controllers` or `services`. Layer-based decomposition produces modules\nthat change together for every feature, defeating the independence goal.\n\n### Decomposition strategies\n\n**Vertical slicing (by feature\u002Fdomain)**\nEach module owns the full stack for a domain: API, business logic, data\naccess. Used in DDD and microservices. Produces high cohesion, low coupling\nacross domains, and clear ownership.\n\n```\nsrc\u002F\n  auth\u002F         ← owns everything about authentication\n  billing\u002F      ← owns everything about billing\n  notifications\u002F ← owns everything about notifications\n```\n\n**Horizontal slicing (by technical layer)**\nModules are organized by their role in the architecture: API handlers,\ndomain logic, infrastructure adapters. Common in traditional layered\narchitectures. Produces coupling across features; harder to decompose later.\n\n**Strangler fig (for existing monoliths)**\nDo not decompose the whole monolith at once. Identify the highest-value\nboundary, extract it, prove the pattern works, then repeat. One module\nat a time. Each extraction should leave the monolith working.\n\n### API surface design\n\nThe public API of a module is its contract with the rest of the system.\nDesign it deliberately:\n\n- **Explicit exports** — prefer explicit export lists (`__all__` in Python,\n  `pub use` in Rust, `index.ts` barrel in TypeScript) over implicit \"everything\n  is public by default.\"\n- **Stable over convenient** — the API should reflect what the module\n  guarantees to support, not every function that happens to be useful.\n  Internal utilities leak into the API accidentally; fight this actively.\n- **Narrow for agents** — a module an agent uses should expose the minimum\n  necessary interface. An agent that can only call `create_user()`,\n  `get_user()`, and `delete_user()` makes fewer mistakes than one that\n  can call any of 47 internal functions.\n- **Versioned changes** — if a module is consumed by other teams or\n  external code, semver its API changes. A breaking change to an internal\n  module is a refactor; a breaking change to a public API is a contract\n  breach.\n\n### Dependency hygiene\n\n- **No circular dependencies** — if module A imports from module B and\n  module B imports from module A, they are the same module. Extract the\n  shared concern into a third module C that neither A nor B modifies.\n- **Dependency direction** — dependencies should flow in one direction:\n  domain ← application ← infrastructure (the dependency rule \u002F clean\n  architecture). Infrastructure modules should never be imported by domain\n  modules.\n- **Vendored vs. pinned** — external dependencies should be pinned to a\n  specific version in a lockfile. \"Latest\" is not a version.\n- **Audit surface** — fewer direct dependencies means fewer potential\n  vulnerabilities. Each dependency is a trust decision; treat it as one.\n\n## Gotchas\n\n- **Decomposing by technical layer instead of domain.** A `controllers\u002F`\n  module that contains every HTTP handler, a `services\u002F` module that contains\n  every business rule, and a `repositories\u002F` module that contains every\n  database query means every feature change touches three modules. Domain\n  decomposition (auth, billing, notifications) produces modules that change\n  for one reason only.\n- **Making the module boundary too fine.** A module per class or per function\n  is not a module — it is a namespace. Modules should contain related\n  concepts that evolve together. If you have 47 modules each containing one\n  function, the coupling has moved from the code to the import graph, which\n  is harder to see and harder to fix.\n- **Ignoring context window size when setting module boundaries.** A module\n  that an agent must load in pieces (because it exceeds the context window)\n  will produce inconsistent reasoning across the pieces. If a module exceeds\n  ~800 lines of code, check whether it can be decomposed. The agent-context\n  constraint is a useful forcing function — a module too large for an agent\n  is usually too large for a human too.\n- **Leaking internal types through the public API.** If the public API of\n  a module returns internal structs, database models, or implementation\n  details, callers couple to the implementation, not the interface. A change\n  to the internal type propagates to all callers. Map to API types at the\n  boundary.\n- **Creating a new module for every decomposition instead of using the\n  strangler fig pattern.** Decomposing a monolith all at once produces a\n  partially-decomposed system that works neither as a monolith nor as\n  modules. Extract one boundary, prove it, then continue. The monolith\n  should remain shippable throughout the decomposition.\n- **Circular dependencies allowed to persist because \"it's internal.\"**\n  Circular dependencies are not a code style issue — they prevent\n  independent testing, independent deployment, and independent reasoning by\n  an agent. Detect them with a linter (e.g., `pylint --disable=all\n  --enable=cyclic-import`, `madge` for JS\u002FTS, `cargo` for Rust) and treat\n  them as build failures.\n- **Not updating AGENTS.md \u002F context budget when modules are added.**\n  A new module means new files an agent might need to load. Update the\n  project's `AGENTS.md` lazy-load guidance when significant new modules are\n  added so the agent knows where to find things without doing filesystem\n  walks.\n\n## Full reference\n\n### Module health checklist\n\nBefore finalizing a module boundary:\n\n- [ ] Can the module be described in one sentence?\n- [ ] Does the public API surface fewer than 10 exported symbols?\n- [ ] Are there fewer than 7 direct internal dependencies?\n- [ ] Does the module fit in ~800 lines \u002F ~8,000 tokens?\n- [ ] Can it be tested independently without loading other modules?\n- [ ] Is there a clear owner (team, person, or agent role)?\n- [ ] Do all imports flow in the correct direction (no circular deps)?\n\n### Detecting coupling problems\n\n| Signal | Likely cause | Fix |\n|---|---|---|\n| Every feature change touches 5+ modules | Layer-based decomposition | Redecompose by domain |\n| Module A and B always deployed together | Implicit coupling, missing abstraction | Extract shared interface |\n| One module imports from 10+ others | \"God module\" antipattern | Split by responsibility |\n| Tests require loading the whole system | No true isolation at module boundary | Introduce interface\u002Fport |\n| Module exceeds 1,000 lines | Too broad scope | Decompose by subdomain |\n\n### Context-window-aware design\n\nFor AI agent consumers, consider documenting module load cost in AGENTS.md:\n\n```markdown\n## Module load guide\n\n| Module | Lines | Load tokens (est.) | When to load |\n|---|---|---|---|\n| auth\u002F | 320 | ~4,000 | auth-related tasks only |\n| billing\u002F | 180 | ~2,200 | billing and subscription tasks |\n| core\u002F | 90 | ~1,100 | always (foundation types) |\n```\n\nThis lets agents lazy-load correctly without filesystem walks.\n","# Software Modularization\n\n## Intro\n\nModularization is the practice of decomposing software into units with\nclear boundaries, stable interfaces, and minimal cross-cutting dependencies.\nGood module design is what makes a codebase navigable by humans — and\nloadable by AI agents without blowing the context window.\n\n## Overview\n\n### The two goals\n\nModularization serves two audiences who want the same thing for different\nreasons:\n\n- **Humans** — small modules are understandable, testable, and deployable\n  independently. The cognitive load of a 500-line module is manageable;\n  a 50,000-line monolith is not.\n- **AI agents** — the agent's context window is finite. A module that an\n  agent can fully load and reason about without truncation produces better\n  results than one that must be partially loaded. Target modules that fit\n  in ~8,000 tokens of context (roughly 500–800 lines of code + docs).\n\n### Module boundary heuristics\n\nUse these signals to find the right cut:\n\n**High cohesion** — everything in the module exists for one reason.\nIf you need two sentences to describe what the module does, it probably\ndoes two things.\n\n**Low coupling** — the module's public API is small and stable. Count\nthe imports from other internal modules: more than 5–7 direct internal\ndependencies is a warning sign.\n\n**Independent deployability** — could you version, test, and deploy this\nmodule on its own? If yes, the boundary is probably right. If it always\nrequires co-deployment with other modules, the boundary may be wrong.\n\n**Domain alignment** — module boundaries should follow business domain\nconcepts, not technical layers. `user-auth` is a better boundary than\n`controllers` or `services`. Layer-based decomposition produces modules\nthat change together for every feature, defeating the independence goal.\n\n### Decomposition strategies\n\n**Vertical slicing (by feature\u002Fdomain)**\nEach module owns the full stack for a domain: API, business logic, data\naccess. Used in DDD and microservices. Produces high cohesion, low coupling\nacross domains, and clear ownership.\n\n```\nsrc\u002F\n  auth\u002F         ← owns everything about authentication\n  billing\u002F      ← owns everything about billing\n  notifications\u002F ← owns everything about notifications\n```\n\n**Horizontal slicing (by technical layer)**\nModules are organized by their role in the architecture: API handlers,\ndomain logic, infrastructure adapters. Common in traditional layered\narchitectures. Produces coupling across features; harder to decompose later.\n\n**Strangler fig (for existing monoliths)**\nDo not decompose the whole monolith at once. Identify the highest-value\nboundary, extract it, prove the pattern works, then repeat. One module\nat a time. Each extraction should leave the monolith working.\n\n### API surface design\n\nThe public API of a module is its contract with the rest of the system.\nDesign it deliberately:\n\n- **Explicit exports** — prefer explicit export lists (`__all__` in Python,\n  `pub use` in Rust, `index.ts` barrel in TypeScript) over implicit \"everything\n  is public by default.\"\n- **Stable over convenient** — the API should reflect what the module\n  guarantees to support, not every function that happens to be useful.\n  Internal utilities leak into the API accidentally; fight this actively.\n- **Narrow for agents** — a module an agent uses should expose the minimum\n  necessary interface. An agent that can only call `create_user()`,\n  `get_user()`, and `delete_user()` makes fewer mistakes than one that\n  can call any of 47 internal functions.\n- **Versioned changes** — if a module is consumed by other teams or\n  external code, semver its API changes. A breaking change to an internal\n  module is a refactor; a breaking change to a public API is a contract\n  breach.\n\n### Dependency hygiene\n\n- **No circular dependencies** — if module A imports from module B and\n  module B imports from module A, they are the same module. Extract the\n  shared concern into a third module C that neither A nor B modifies.\n- **Dependency direction** — dependencies should flow in one direction:\n  domain ← application ← infrastructure (the dependency rule \u002F clean\n  architecture). Infrastructure modules should never be imported by domain\n  modules.\n- **Vendored vs. pinned** — external dependencies should be pinned to a\n  specific version in a lockfile. \"Latest\" is not a version.\n- **Audit surface** — fewer direct dependencies means fewer potential\n  vulnerabilities. Each dependency is a trust decision; treat it as one.\n\n## Gotchas\n\n- **Decomposing by technical layer instead of domain.** A `controllers\u002F`\n  module that contains every HTTP handler, a `services\u002F` module that contains\n  every business rule, and a `repositories\u002F` module that contains every\n  database query means every feature change touches three modules. Domain\n  decomposition (auth, billing, notifications) produces modules that change\n  for one reason only.\n- **Making the module boundary too fine.** A module per class or per function\n  is not a module — it is a namespace. Modules should contain related\n  concepts that evolve together. If you have 47 modules each containing one\n  function, the coupling has moved from the code to the import graph, which\n  is harder to see and harder to fix.\n- **Ignoring context window size when setting module boundaries.** A module\n  that an agent must load in pieces (because it exceeds the context window)\n  will produce inconsistent reasoning across the pieces. If a module exceeds\n  ~800 lines of code, check whether it can be decomposed. The agent-context\n  constraint is a useful forcing function — a module too large for an agent\n  is usually too large for a human too.\n- **Leaking internal types through the public API.** If the public API of\n  a module returns internal structs, database models, or implementation\n  details, callers couple to the implementation, not the interface. A change\n  to the internal type propagates to all callers. Map to API types at the\n  boundary.\n- **Creating a new module for every decomposition instead of using the\n  strangler fig pattern.** Decomposing a monolith all at once produces a\n  partially-decomposed system that works neither as a monolith nor as\n  modules. Extract one boundary, prove it, then continue. The monolith\n  should remain shippable throughout the decomposition.\n- **Circular dependencies allowed to persist because \"it's internal.\"**\n  Circular dependencies are not a code style issue — they prevent\n  independent testing, independent deployment, and independent reasoning by\n  an agent. Detect them with a linter (e.g., `pylint --disable=all\n  --enable=cyclic-import`, `madge` for JS\u002FTS, `cargo` for Rust) and treat\n  them as build failures.\n- **Not updating AGENTS.md \u002F context budget when modules are added.**\n  A new module means new files an agent might need to load. Update the\n  project's `AGENTS.md` lazy-load guidance when significant new modules are\n  added so the agent knows where to find things without doing filesystem\n  walks.\n\n## Full reference\n\n### Module health checklist\n\nBefore finalizing a module boundary:\n\n- [ ] Can the module be described in one sentence?\n- [ ] Does the public API surface fewer than 10 exported symbols?\n- [ ] Are there fewer than 7 direct internal dependencies?\n- [ ] Does the module fit in ~800 lines \u002F ~8,000 tokens?\n- [ ] Can it be tested independently without loading other modules?\n- [ ] Is there a clear owner (team, person, or agent role)?\n- [ ] Do all imports flow in the correct direction (no circular deps)?\n\n### Detecting coupling problems\n\n| Signal | Likely cause | Fix |\n|---|---|---|\n| Every feature change touches 5+ modules | Layer-based decomposition | Redecompose by domain |\n| Module A and B always deployed together | Implicit coupling, missing abstraction | Extract shared interface |\n| One module imports from 10+ others | \"God module\" antipattern | Split by responsibility |\n| Tests require loading the whole system | No true isolation at module boundary | Introduce interface\u002Fport |\n| Module exceeds 1,000 lines | Too broad scope | Decompose by subdomain |\n\n### Context-window-aware design\n\nFor AI agent consumers, consider documenting module load cost in AGENTS.md:\n\n```markdown\n## Module load guide\n\n| Module | Lines | Load tokens (est.) | When to load |\n|---|---|---|---|\n| auth\u002F | 320 | ~4,000 | auth-related tasks only |\n| billing\u002F | 180 | ~2,200 | billing and subscription tasks |\n| core\u002F | 90 | ~1,100 | always (foundation types) |\n```\n\nThis lets agents lazy-load correctly without filesystem walks.\n",{"name":5,"metadata":45,"description":51},{"processkit":46},{"id":47,"created":48,"version":49,"category":29,"apiVersion":50},"SKILL-software-modularization",1775606400000,"1.0.0","processkit.projectious.work\u002Fv1","Design and evaluate module and package boundaries for maintainability, low coupling, and AI agent context efficiency.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fengineering\u002Fsoftware-modularization","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add projectious-work\u002Fprocesskit --skill software-modularization",{"tool":65,"command":66},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill software-modularization",{"tool":68,"command":69},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill software-modularization","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.2\u002Fcontext\u002Fskills\u002Fengineering\u002Fsoftware-modularization\u002FSKILL.md",true,[],[74,97,116,137,154,172],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":83,"publishedAt":40},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[84,85,86,87,28,88,30,89,90,91,76,92,93,94,37,95,96],"management","skill management","create","update","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":104,"publishedAt":40},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[103],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},[84,105,106,107,108,109,88,30,110,111,90,112,32,113,92,114,115],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","deterministic","contract","mode",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":40},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[84,123,124,86,87,125,88,30,126,127,128,129,92,130,131,132,133,134,135,136],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":40},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[84,91,144,86,88,145,146,110,147,126,90,148,149,92,150,151,131,152,37,153],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":40},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[161,162,163,164,88,165,166,167,30,168,169,170,171],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":40},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[84,179,180,86,87,125,88,145,30,89,126,181,90,128,92,151,131,132,182,96],"capability","capability management","queries","changes"]