[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WXM35E49M9ZM2C2ANNBRMX":3,"skill-same:01M6WXM35E49M9ZM2C2ANNBRMX":77},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":14,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6WXM35E49M9ZM2C2ANNBRMX","code-generation",null,"Code generation patterns — template engines, AST manipulation, scaffolding, build-step generation. Use when building or extending a code generator, choosing a template engine, deciding whether to generate code or write an abstraction, adding codegen as a build step, or implementing macro\u002FAST transformations.","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.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fcode-generation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,5,35,36,37,38,39,40,41,42],"code","Code Generation","generation","when","generate","implementing","v1","generator","as","scaffolding","build","use","template engine","write","ast","work","engine","template","macro","2026-11-10 10:12:30",false,"---\nname: code-generation\ndescription: |\n  Code generation patterns — template engines, AST manipulation, scaffolding, build-step generation. Use when building or extending a code generator, choosing a template engine, deciding whether to generate code or write an abstraction, adding codegen as a build step, or implementing macro\u002FAST transformations.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-code-generation\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# Code Generation\n\n## Intro\n\nCodegen produces source files from a higher-level input — a schema,\nDSL, AST, or template — instead of having humans hand-write the\noutput. It pays off when output spans multiple languages, must be\nzero-dependency, or comes from a mechanical mapping. It's a liability\nwhen a plain library would do.\n\n## Overview\n\n### Generate vs. abstract\n\nThe first decision is whether to generate at all.\n\n**Generate when:** output spans multiple languages, must be\nzero-dependency at runtime, or the input-to-output mapping is\nmechanical and repetitive (OpenAPI clients, protobuf stubs, GraphQL\ntyped clients).\n\n**Abstract when:** a shared library with configuration solves the\nproblem, runtime flexibility matters, or maintenance of N generated\nfiles would exceed maintenance of one library.\n\nIf everything is in one language and there is no zero-dep constraint,\ndefault to a library.\n\n### Template engines\n\n| Engine | Language | Best for |\n|---|---|---|\n| Jinja2 | Python | Config files, IaC, multi-language output |\n| Handlebars | JS\u002FTS | Logic-less templates, client-side rendering |\n| EJS | JS\u002FTS | Embedded JS logic, quick prototypes |\n| Tera | Rust | Rust-native projects, Jinja2-like |\n| Go templates | Go | Go projects, kubectl\u002FHelm templates |\n\nRules of thumb:\n\n- Keep templates logic-free. Push logic into the data model that\n  feeds the template.\n- Use template inheritance\u002Fblocks for shared structure across\n  variants.\n- Store templates alongside the generator, not in the output\n  directory.\n- Emit a header comment on every generated file:\n  `\u002F\u002F Code generated by \u003Ctool> — DO NOT EDIT.`\n\n### AST manipulation\n\nUse language-specific parsers when transformations depend on\nsyntactic context, must guarantee valid output, or are too complex\nfor regex. Examples: `syn` (Rust), `ast` and `libcst` (Python),\n`ts-morph` (TypeScript), `javaparser` (Java).\n\nThe pattern is always the same: parse source to AST, transform the\ntree, emit back to source. Preserve formatting and comments where\nthe library allows it.\n\n### Scaffolding tools\n\nCookiecutter, Yeoman, `cargo-generate`, `create-*` CLIs.\n\n- Define templates with placeholder variables, sensible defaults,\n  and validation.\n- Scaffolded projects must compile and run immediately. Include\n  tests, linting, and CI config out of the box.\n- Pin the scaffolder version so reruns are deterministic.\n\n### Build-step generation\n\nWhen codegen runs as part of the build:\n\n- Store the source-of-truth (schema, spec, DSL) in version control.\n- Fail the build if generated output differs from committed files\n  (run codegen, then `git diff --exit-code`).\n- Pin the generator version. Cache intermediate artifacts.\n- Provide a single command to regenerate everything: `make generate`\n  or `just generate`.\n\n### Keeping generated code in sync\n\n- Mark generated files clearly: header comment, `.generated.` infix\n  in filename, or a manifest file listing all generated paths.\n- One command to regenerate all of it.\n- CI check that runs codegen and diffs against committed files.\n- Never hand-edit generated files. Fix the template or input\n  instead, then regenerate.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Hand-editing generated files.** Generated files are overwritten on the next regeneration run. All fixes must go to the template or input schema, then regenerate. Without this discipline, edits silently accumulate until the next full regeneration wipes them.\n- **Missing `DO NOT EDIT` header.** Without a clear header, future contributors will edit the output, lose work, and curse the system. Every generated file must declare itself generated with the tool name and source.\n- **No CI check for generator drift.** If CI does not run codegen and diff against committed output, the generator and the checked-in files will silently diverge. Add `git diff --exit-code` after running the generator in CI.\n- **Logic embedded in the template.** Templates with embedded conditionals, loops, and computations are untestable and hard to debug. Push all logic into the data model that feeds the template; keep the template a dumb projection.\n- **Unpinned generator version.** If the generator is invoked without a pinned version, reruns may produce different output. Pin the generator version the same way you pin any other tool dependency.\n- **Generating when a library would do.** The generate-vs-abstract decision defaults to \"abstract\" when everything is in one language and there is no zero-dependency constraint. Proposing codegen for a same-language, same-repo problem is usually over-engineering.\n- **No single regeneration command.** \"Run these eight steps in order\" does not survive a year. Every project with codegen needs a single command — `make generate`, `just generate`, or equivalent — that regenerates everything from scratch.\n\n## Full reference\n\n### Macro systems\n\nRust `proc_macro`, Lisp macros, the C preprocessor, and Scala\nmacros all sit on the codegen spectrum but operate at compile time\nwithin the language.\n\n- Prefer **declarative macros** (`macro_rules!`) over **procedural\n  macros** when the pattern is simple. Procedural macros are powerful\n  but hard to debug and slow to compile.\n- Always document macro expansion. Provide `cargo expand` (or\n  equivalent) so consumers can inspect what the macro produces.\n- Keep generated code minimal — delegate to library functions for\n  complex logic. The macro should be a thin shell around library\n  calls, not a place to embed an entire algorithm.\n- Avoid macros that generate names by string concatenation; they\n  defeat tooling like jump-to-definition.\n\n### When generated code wins over a library\n\nThere are real cases where codegen beats abstraction even in a\nsingle language:\n\n- Output must be inspectable and debuggable as plain source (e.g.\n  generated SQL migrations).\n- Performance demands inlining that a runtime abstraction can't\n  achieve.\n- The target language doesn't support the abstraction you'd need\n  (no generics, no reflection, no macros).\n- Cross-team contracts: the spec is the API, generated code is just\n  the implementation.\n\n### Anti-patterns\n\n- **Hand-edited generated files.** They will be overwritten. Fix\n  the source.\n- **Generated files not in version control.** Reviewers can't see\n  what changed. Commit them and gate on diff.\n- **Logic embedded in templates.** Push computation into the data\n  model and keep the template a dumb projection.\n- **No `DO NOT EDIT` header.** Future contributors will edit the\n  output, lose work, and curse you.\n- **No regeneration command.** \"Run these eight steps in order\"\n  doesn't survive a year.\n- **Mixing generators.** Two tools writing into the same file with\n  different conventions ends in chaos. Pick one tool per file.\n\n### Worked scenarios\n\n**OpenAPI -> TypeScript + Python clients.** Read the spec, evaluate\noptions (`openapi-generator` for multi-language vs. `openapi-typescript`\nfor TS-only). Choose `openapi-generator` for the multi-language\nrequirement. Wire `generate.sh` producing both clients with\n`DO NOT EDIT` headers, plus a CI step that runs the generator and\nfails on diff.\n\n**Same 40-line DB pattern in every service.** All services are\nPython; variation is just table name and columns. Recommend a shared\nlibrary: single language eliminates the codegen advantage, the\nlibrary allows runtime changes, and one library is less to maintain\nthan N generated files.\n\n**Renaming `log_event` to `emit_event` across 200 files.** Find\u002F\nreplace hits false positives in strings and comments. Write a\nts-morph (or libcst) codemod that parses each file, finds call\nexpressions where the callee is `log_event`, renames to `emit_event`,\nand writes back preserving formatting. Run it once; commit the diff.\n","# Code Generation\n\n## Intro\n\nCodegen produces source files from a higher-level input — a schema,\nDSL, AST, or template — instead of having humans hand-write the\noutput. It pays off when output spans multiple languages, must be\nzero-dependency, or comes from a mechanical mapping. It's a liability\nwhen a plain library would do.\n\n## Overview\n\n### Generate vs. abstract\n\nThe first decision is whether to generate at all.\n\n**Generate when:** output spans multiple languages, must be\nzero-dependency at runtime, or the input-to-output mapping is\nmechanical and repetitive (OpenAPI clients, protobuf stubs, GraphQL\ntyped clients).\n\n**Abstract when:** a shared library with configuration solves the\nproblem, runtime flexibility matters, or maintenance of N generated\nfiles would exceed maintenance of one library.\n\nIf everything is in one language and there is no zero-dep constraint,\ndefault to a library.\n\n### Template engines\n\n| Engine | Language | Best for |\n|---|---|---|\n| Jinja2 | Python | Config files, IaC, multi-language output |\n| Handlebars | JS\u002FTS | Logic-less templates, client-side rendering |\n| EJS | JS\u002FTS | Embedded JS logic, quick prototypes |\n| Tera | Rust | Rust-native projects, Jinja2-like |\n| Go templates | Go | Go projects, kubectl\u002FHelm templates |\n\nRules of thumb:\n\n- Keep templates logic-free. Push logic into the data model that\n  feeds the template.\n- Use template inheritance\u002Fblocks for shared structure across\n  variants.\n- Store templates alongside the generator, not in the output\n  directory.\n- Emit a header comment on every generated file:\n  `\u002F\u002F Code generated by \u003Ctool> — DO NOT EDIT.`\n\n### AST manipulation\n\nUse language-specific parsers when transformations depend on\nsyntactic context, must guarantee valid output, or are too complex\nfor regex. Examples: `syn` (Rust), `ast` and `libcst` (Python),\n`ts-morph` (TypeScript), `javaparser` (Java).\n\nThe pattern is always the same: parse source to AST, transform the\ntree, emit back to source. Preserve formatting and comments where\nthe library allows it.\n\n### Scaffolding tools\n\nCookiecutter, Yeoman, `cargo-generate`, `create-*` CLIs.\n\n- Define templates with placeholder variables, sensible defaults,\n  and validation.\n- Scaffolded projects must compile and run immediately. Include\n  tests, linting, and CI config out of the box.\n- Pin the scaffolder version so reruns are deterministic.\n\n### Build-step generation\n\nWhen codegen runs as part of the build:\n\n- Store the source-of-truth (schema, spec, DSL) in version control.\n- Fail the build if generated output differs from committed files\n  (run codegen, then `git diff --exit-code`).\n- Pin the generator version. Cache intermediate artifacts.\n- Provide a single command to regenerate everything: `make generate`\n  or `just generate`.\n\n### Keeping generated code in sync\n\n- Mark generated files clearly: header comment, `.generated.` infix\n  in filename, or a manifest file listing all generated paths.\n- One command to regenerate all of it.\n- CI check that runs codegen and diffs against committed files.\n- Never hand-edit generated files. Fix the template or input\n  instead, then regenerate.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Hand-editing generated files.** Generated files are overwritten on the next regeneration run. All fixes must go to the template or input schema, then regenerate. Without this discipline, edits silently accumulate until the next full regeneration wipes them.\n- **Missing `DO NOT EDIT` header.** Without a clear header, future contributors will edit the output, lose work, and curse the system. Every generated file must declare itself generated with the tool name and source.\n- **No CI check for generator drift.** If CI does not run codegen and diff against committed output, the generator and the checked-in files will silently diverge. Add `git diff --exit-code` after running the generator in CI.\n- **Logic embedded in the template.** Templates with embedded conditionals, loops, and computations are untestable and hard to debug. Push all logic into the data model that feeds the template; keep the template a dumb projection.\n- **Unpinned generator version.** If the generator is invoked without a pinned version, reruns may produce different output. Pin the generator version the same way you pin any other tool dependency.\n- **Generating when a library would do.** The generate-vs-abstract decision defaults to \"abstract\" when everything is in one language and there is no zero-dependency constraint. Proposing codegen for a same-language, same-repo problem is usually over-engineering.\n- **No single regeneration command.** \"Run these eight steps in order\" does not survive a year. Every project with codegen needs a single command — `make generate`, `just generate`, or equivalent — that regenerates everything from scratch.\n\n## Full reference\n\n### Macro systems\n\nRust `proc_macro`, Lisp macros, the C preprocessor, and Scala\nmacros all sit on the codegen spectrum but operate at compile time\nwithin the language.\n\n- Prefer **declarative macros** (`macro_rules!`) over **procedural\n  macros** when the pattern is simple. Procedural macros are powerful\n  but hard to debug and slow to compile.\n- Always document macro expansion. Provide `cargo expand` (or\n  equivalent) so consumers can inspect what the macro produces.\n- Keep generated code minimal — delegate to library functions for\n  complex logic. The macro should be a thin shell around library\n  calls, not a place to embed an entire algorithm.\n- Avoid macros that generate names by string concatenation; they\n  defeat tooling like jump-to-definition.\n\n### When generated code wins over a library\n\nThere are real cases where codegen beats abstraction even in a\nsingle language:\n\n- Output must be inspectable and debuggable as plain source (e.g.\n  generated SQL migrations).\n- Performance demands inlining that a runtime abstraction can't\n  achieve.\n- The target language doesn't support the abstraction you'd need\n  (no generics, no reflection, no macros).\n- Cross-team contracts: the spec is the API, generated code is just\n  the implementation.\n\n### Anti-patterns\n\n- **Hand-edited generated files.** They will be overwritten. Fix\n  the source.\n- **Generated files not in version control.** Reviewers can't see\n  what changed. Commit them and gate on diff.\n- **Logic embedded in templates.** Push computation into the data\n  model and keep the template a dumb projection.\n- **No `DO NOT EDIT` header.** Future contributors will edit the\n  output, lose work, and curse you.\n- **No regeneration command.** \"Run these eight steps in order\"\n  doesn't survive a year.\n- **Mixing generators.** Two tools writing into the same file with\n  different conventions ends in chaos. Pick one tool per file.\n\n### Worked scenarios\n\n**OpenAPI -> TypeScript + Python clients.** Read the spec, evaluate\noptions (`openapi-generator` for multi-language vs. `openapi-typescript`\nfor TS-only). Choose `openapi-generator` for the multi-language\nrequirement. Wire `generate.sh` producing both clients with\n`DO NOT EDIT` headers, plus a CI step that runs the generator and\nfails on diff.\n\n**Same 40-line DB pattern in every service.** All services are\nPython; variation is just table name and columns. Recommend a shared\nlibrary: single language eliminates the codegen advantage, the\nlibrary allows runtime changes, and one library is less to maintain\nthan N generated files.\n\n**Renaming `log_event` to `emit_event` across 200 files.** Find\u002F\nreplace hits false positives in strings and comments. Write a\nts-morph (or libcst) codemod that parses each file, finds call\nexpressions where the callee is `log_event`, renames to `emit_event`,\nand writes back preserving formatting. Run it once; commit the diff.\n",{"name":5,"metadata":48,"description":55},{"processkit":49},{"id":50,"created":51,"version":52,"category":53,"apiVersion":54},"SKILL-code-generation",1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Code generation patterns — template engines, AST manipulation, scaffolding, build-step generation. Use when building or extending a code generator, choosing a template engine, deciding whether to generate code or write an abstraction, adding codegen as a build step, or implementing macro\u002FAST transformations.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fcode-generation","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":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add projectious-work\u002Fprocesskit --skill code-generation",{"tool":69,"command":70},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill code-generation",{"tool":72,"command":73},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill code-generation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.11.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fcode-generation\u002FSKILL.md",true,[],[78,103,123,144,161,179],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":89,"publishedAt":43},"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",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[90,91,92,93,94,95,39,96,97,98,80,99,32,100,30,101,102],"management","skill management","create","update","package","alpha","list","manage","ontology","get","manifests","skill package","transition",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":43},"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",[109],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},[90,111,112,113,114,115,95,39,116,117,97,118,119,120,99,121,122],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":43},"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",[],[90,130,131,92,93,132,95,39,133,134,135,136,99,137,138,139,140,141,142,143],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":43},"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",[],[90,98,151,92,95,152,153,116,154,133,97,155,156,99,157,158,138,159,30,160],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":43},"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",[],[168,169,170,171,95,172,173,174,39,175,176,177,178],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":43},"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",[],[90,186,187,92,93,132,95,152,39,96,133,188,97,135,99,158,138,139,189,102],"capability","capability management","queries","changes"]