[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D8G9D3FSQH7EZCZE8G0AMM":3,"skill-same:01M6D8G9D3FSQH7EZCZE8G0AMM":127},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6D8G9D3FSQH7EZCZE8G0AMM","cli-as-harness",null,"Author CLI surfaces as agent-facing documentation, especially `--help` and actionable error messages. Use with any language or parser design when adding or changing a CLI interface, improving help text or validation errors, moving command reference out of AGENTS.md \u002F CLAUDE.md \u002F a README \u002F a skill and into CLI surfaces, or making errors suggest the corrected command line or tool call.","jesse-black\u002Fdocgarden","jesse-black","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5840911?v=4","01M6D8G07TP5PJH5NHT9YJ8E1Y","Jesse Black","01M6D8G0C92CS19125JXMPEVSQ",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcli-as-harness\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"cli","cli as harness","as","harness","validation","command line","help","error messages","messages","tool","text","parser","README","command","use","reference","surfaces","call","documentation","design","2026-11-10 10:12:30",false,"---\nname: cli-as-harness\ndescription: Author CLI surfaces as agent-facing documentation, especially `--help` and actionable error messages. Use with any language or parser design when adding or changing a CLI interface, improving help text or validation errors, moving command reference out of AGENTS.md \u002F CLAUDE.md \u002F a README \u002F a skill and into CLI surfaces, or making errors suggest the corrected command line or tool call.\n---\n\n# Authoring CLI surfaces as harness\n\nIn agentic engineering the **harness** is everything around the model that shapes what it can do\nand know — the agent loop, tool wiring, assembled context, and instructions. Most harness\ninstruction is *pushed*: baked into a system prompt, an AGENTS.md, or a tool description, all\nstatic and centralized. CLI surfaces are underused local harness: `--help` carries the command\nreference, and validation errors carry the recovery path when a command is malformed. Treating a\nCLI as harness means deliberately authoring both for an agent reader — not just a human — so the\ninstalled tool explains its current interface and how to recover from common invalid calls.\n\nThe organizing rule: **top-level `--help` owns what the tool is for and when to use it;\nsubcommand `--help` owns command-local semantics; error messages own local recovery from invalid\ncommand use; a skill or AGENTS.md owns cross-tool workflow, policy, and anything that needs the\nbigger picture to apply safely.** Most staleness and duplication in agent docs comes from copying\na flag list into AGENTS.md, where it rots the moment the CLI changes.\n\n## Prefer declarative parsers\n\nFor new CLIs, prefer the ecosystem's standard declarative parser so behavior, help, and parse\nerrors share a source of truth. For an existing hand-rolled parser, improve its current surfaces\nin place unless migration is in scope. Consider migration when duplicated definitions or\nscattered validation repeatedly cause drift; do not expand a narrow help or error task solely to\nreplace the parser.\n\n## Authoring `--help`\n\nIf you own the CLI, put the canonical, agent-facing instruction **in the parser's command\ndefinitions**. Use the project's existing parser framework and conventions; the principle applies\nequally to Python `argparse` or Click, Rust clap, Node.js Commander, Go Cobra, and other CLI\nparsers. Map these semantic roles to the framework's own API:\n\n| Semantic role | Put in the parser or command definition |\n|---------------|-----------------------------------------|\n| Root purpose | Summary and long description explaining what the tool does and when to use it |\n| Option contract | Help text, value shape, default, allowed values, and whether it is required |\n| Subcommand contract | Command-local description, options, examples, and gotchas |\n| Extended guidance | Framework-supported footer, after-help, or equivalent verbatim section |\n\nPrefer framework-generated usage, option, and default output over hand-maintained copies. Keep\nexamples and longer guidance beside the command definition, or in the framework's help hooks, and\npreserve intentional line breaks with the framework's own formatter.\n\nThen make instruction files carry a **pointer, not a copy**: ``Run `tool \u003Ccmd> --help` for the\nauthoritative reference.``\n\n### What to put in `--help` (beyond the bare flags)\n\nA flag list is the floor, not the ceiling. The high-value additions for an agent reader:\n\n- **Examples** — concrete, copy-pasteable invocations. Subcommand help usually wants examples,\n  not recipes: one realistic command line teaches more than a paragraph.\n  > `Example:  tool deploy --env staging --dry-run    # preview without applying`\n- **Recipes** — short task flows for top-level `tool --help`, so the agent sees the intended\n  *order* for common end-to-end work inside that tool. Keep them brief and point to the exact\n  subcommands; do not try to replace subcommand help.\n  > `Recipe (log then review):  tool add ... && tool list --due`\n- **Isolated guidance** — advice correct on its own, since each help page must stand without\n  surrounding narrative. Good: \"`--output FILE` writes to `FILE` instead of stdout.\"\n- **Gotchas** — constraints that produce confusing errors if missed. Put each rule next to the\n  flag, then name it in the matching error and suggest the correction.\n- **Tool when\u002Fwhy** — the root `tool --help` should say when to reach for the tool at all, and host\n  the recipes that span its own subcommands.\n\n**The isolation test** decides what qualifies: *would this instruction still be correct and\nactionable for an agent that read only this `--help` page and nothing else?* If yes, it belongs in\n`--help`. If it only makes sense as one step of a larger cross-tool workflow or repo policy, it\nbelongs in a skill or AGENTS.md instead.\n\n## Authoring error messages\n\nError messages are part of the harness because agents often see them at the exact moment they need\nto recover. Keep them short, specific, and corrective:\n\n- State what failed using the same flag, value, and subcommand names shown in `--help`.\n- When the fix is unambiguous, include a runnable correction. Render dynamic values safely for the\n  target interface: shell-quote shell values, use `--` before positional filenames when supported,\n  or prefer a structured tool call or argument list.\n- For validation constraints, name the accepted values or required pairings directly in the error.\n- If an error teaches a rule that should have been known before execution, add the same rule to the\n  relevant `--help` page so the command is self-documenting before and after failure.\n- Limit recovery text to the immediate correction; omit unrelated workflow and rationale.\n\nFor example, a POSIX-shell recovery command for files `file 1` and `file2` is:\n\n```bash\ngit add -N -- 'file 1' file2\n```\n\nUse the framework's native parse errors for syntax it already understands, such as unknown options,\nmissing values, and invalid enumerated values. Add application errors for semantic constraints the\nframework cannot express. Keep terminology and usage shape consistent across both paths.\n\n## Implementation workflow\n\n1. Identify the parser or command-definition source and help-customization hooks before\n   editing, and put each fact at the narrowest definition that owns it.\n2. Generate root and affected subcommand help from the executable and inspect the rendered output,\n   including wrapping and preserved examples.\n3. Exercise representative invalid calls; verify each error names the bad input and, when the fix is\n   unambiguous, gives a runnable correction. Cover both paths with tests in the project's style,\n   asserting durable contract text over incidental spacing.\n4. Remove duplicated command reference from instruction files, replacing it with a help pointer.\n\n## What to keep out of CLI surfaces\n\nThe isolation test draws the line. Anything that only makes sense with cross-tool workflow, repo\npolicy, the *rationale* behind a convention, or multi-tool orchestration in view belongs in a skill\nor AGENTS.md — not in `--help` or an error, where it can't be applied safely from the page alone.\nConversely, don't leave flag enumerations stranded in AGENTS.md, where they rot the moment the CLI\nchanges; those belong in the parser. Each surface does what it's structurally good at.\n","# Authoring CLI surfaces as harness\n\nIn agentic engineering the **harness** is everything around the model that shapes what it can do\nand know — the agent loop, tool wiring, assembled context, and instructions. Most harness\ninstruction is *pushed*: baked into a system prompt, an AGENTS.md, or a tool description, all\nstatic and centralized. CLI surfaces are underused local harness: `--help` carries the command\nreference, and validation errors carry the recovery path when a command is malformed. Treating a\nCLI as harness means deliberately authoring both for an agent reader — not just a human — so the\ninstalled tool explains its current interface and how to recover from common invalid calls.\n\nThe organizing rule: **top-level `--help` owns what the tool is for and when to use it;\nsubcommand `--help` owns command-local semantics; error messages own local recovery from invalid\ncommand use; a skill or AGENTS.md owns cross-tool workflow, policy, and anything that needs the\nbigger picture to apply safely.** Most staleness and duplication in agent docs comes from copying\na flag list into AGENTS.md, where it rots the moment the CLI changes.\n\n## Prefer declarative parsers\n\nFor new CLIs, prefer the ecosystem's standard declarative parser so behavior, help, and parse\nerrors share a source of truth. For an existing hand-rolled parser, improve its current surfaces\nin place unless migration is in scope. Consider migration when duplicated definitions or\nscattered validation repeatedly cause drift; do not expand a narrow help or error task solely to\nreplace the parser.\n\n## Authoring `--help`\n\nIf you own the CLI, put the canonical, agent-facing instruction **in the parser's command\ndefinitions**. Use the project's existing parser framework and conventions; the principle applies\nequally to Python `argparse` or Click, Rust clap, Node.js Commander, Go Cobra, and other CLI\nparsers. Map these semantic roles to the framework's own API:\n\n| Semantic role | Put in the parser or command definition |\n|---------------|-----------------------------------------|\n| Root purpose | Summary and long description explaining what the tool does and when to use it |\n| Option contract | Help text, value shape, default, allowed values, and whether it is required |\n| Subcommand contract | Command-local description, options, examples, and gotchas |\n| Extended guidance | Framework-supported footer, after-help, or equivalent verbatim section |\n\nPrefer framework-generated usage, option, and default output over hand-maintained copies. Keep\nexamples and longer guidance beside the command definition, or in the framework's help hooks, and\npreserve intentional line breaks with the framework's own formatter.\n\nThen make instruction files carry a **pointer, not a copy**: ``Run `tool \u003Ccmd> --help` for the\nauthoritative reference.``\n\n### What to put in `--help` (beyond the bare flags)\n\nA flag list is the floor, not the ceiling. The high-value additions for an agent reader:\n\n- **Examples** — concrete, copy-pasteable invocations. Subcommand help usually wants examples,\n  not recipes: one realistic command line teaches more than a paragraph.\n  > `Example:  tool deploy --env staging --dry-run    # preview without applying`\n- **Recipes** — short task flows for top-level `tool --help`, so the agent sees the intended\n  *order* for common end-to-end work inside that tool. Keep them brief and point to the exact\n  subcommands; do not try to replace subcommand help.\n  > `Recipe (log then review):  tool add ... && tool list --due`\n- **Isolated guidance** — advice correct on its own, since each help page must stand without\n  surrounding narrative. Good: \"`--output FILE` writes to `FILE` instead of stdout.\"\n- **Gotchas** — constraints that produce confusing errors if missed. Put each rule next to the\n  flag, then name it in the matching error and suggest the correction.\n- **Tool when\u002Fwhy** — the root `tool --help` should say when to reach for the tool at all, and host\n  the recipes that span its own subcommands.\n\n**The isolation test** decides what qualifies: *would this instruction still be correct and\nactionable for an agent that read only this `--help` page and nothing else?* If yes, it belongs in\n`--help`. If it only makes sense as one step of a larger cross-tool workflow or repo policy, it\nbelongs in a skill or AGENTS.md instead.\n\n## Authoring error messages\n\nError messages are part of the harness because agents often see them at the exact moment they need\nto recover. Keep them short, specific, and corrective:\n\n- State what failed using the same flag, value, and subcommand names shown in `--help`.\n- When the fix is unambiguous, include a runnable correction. Render dynamic values safely for the\n  target interface: shell-quote shell values, use `--` before positional filenames when supported,\n  or prefer a structured tool call or argument list.\n- For validation constraints, name the accepted values or required pairings directly in the error.\n- If an error teaches a rule that should have been known before execution, add the same rule to the\n  relevant `--help` page so the command is self-documenting before and after failure.\n- Limit recovery text to the immediate correction; omit unrelated workflow and rationale.\n\nFor example, a POSIX-shell recovery command for files `file 1` and `file2` is:\n\n```bash\ngit add -N -- 'file 1' file2\n```\n\nUse the framework's native parse errors for syntax it already understands, such as unknown options,\nmissing values, and invalid enumerated values. Add application errors for semantic constraints the\nframework cannot express. Keep terminology and usage shape consistent across both paths.\n\n## Implementation workflow\n\n1. Identify the parser or command-definition source and help-customization hooks before\n   editing, and put each fact at the narrowest definition that owns it.\n2. Generate root and affected subcommand help from the executable and inspect the rendered output,\n   including wrapping and preserved examples.\n3. Exercise representative invalid calls; verify each error names the bad input and, when the fix is\n   unambiguous, gives a runnable correction. Cover both paths with tests in the project's style,\n   asserting durable contract text over incidental spacing.\n4. Remove duplicated command reference from instruction files, replacing it with a help pointer.\n\n## What to keep out of CLI surfaces\n\nThe isolation test draws the line. Anything that only makes sense with cross-tool workflow, repo\npolicy, the *rationale* behind a convention, or multi-tool orchestration in view belongs in a skill\nor AGENTS.md — not in `--help` or an error, where it can't be applied safely from the page alone.\nConversely, don't leave flag enumerations stranded in AGENTS.md, where they rot the moment the CLI\nchanges; those belong in the parser. Each surface does what it's structurally good at.\n",{"name":5,"description":7},"main","a3937e6e80074000b5213e737409f99f6a8443e2",".agents\u002Fskills\u002Fcli-as-harness",0,"https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden","https:\u002F\u002Fgithub.com\u002Fjesse-black","Building the accessible communication tool I wish I'd had sooner.","2026-07-22 22:14:44",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add jesse-black\u002Fdocgarden --skill cli-as-harness",{"tool":63,"command":64},"bunx","bunx skills add jesse-black\u002Fdocgarden --skill cli-as-harness",{"tool":66,"command":67},"pnpm","pnpm dlx skills add jesse-black\u002Fdocgarden --skill cli-as-harness","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcli-as-harness\u002FSKILL.md",true,[71,77,83,87,91,95,99,103,107,111,115,119,123],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"checklist.md","REFERENCE","参考文档",10101,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Fchecklist.md",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"documentation-requirements.csv","ASSET","资产文件",8076,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Fdocumentation-requirements.csv",{"path":84,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":85,"sourceHtmlUrl":86},"instructions.md",5164,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Finstructions.md",{"path":88,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":89,"sourceHtmlUrl":90},"templates\u002Fdeep-dive-template.md",5854,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Ftemplates\u002Fdeep-dive-template.md",{"path":92,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":93,"sourceHtmlUrl":94},"templates\u002Findex-template.md",4510,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Ftemplates\u002Findex-template.md",{"path":96,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":97,"sourceHtmlUrl":98},"templates\u002Fproject-overview-template.md",1951,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Ftemplates\u002Fproject-overview-template.md",{"path":100,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":101,"sourceHtmlUrl":102},"templates\u002Fproject-scan-report-schema.json",4836,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Ftemplates\u002Fproject-scan-report-schema.json",{"path":104,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":105,"sourceHtmlUrl":106},"templates\u002Fsource-tree-template.md",2160,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Ftemplates\u002Fsource-tree-template.md",{"path":108,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":109,"sourceHtmlUrl":110},"workflow.md",719,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Fworkflow.md",{"path":112,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":113,"sourceHtmlUrl":114},"workflows\u002Fdeep-dive-instructions.md",11909,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Fworkflows\u002Fdeep-dive-instructions.md",{"path":116,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":117,"sourceHtmlUrl":118},"workflows\u002Fdeep-dive-workflow.md",979,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Fworkflows\u002Fdeep-dive-workflow.md",{"path":120,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":121,"sourceHtmlUrl":122},"workflows\u002Ffull-scan-instructions.md",43200,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Fworkflows\u002Ffull-scan-instructions.md",{"path":124,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":125,"sourceHtmlUrl":126},"workflows\u002Ffull-scan-workflow.md",970,"https:\u002F\u002Fgithub.com\u002FCanVc\u002Fdoc-chat\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fbmad-document-project\u002Fworkflows\u002Ffull-scan-workflow.md",[128,140,148,170,185,198],{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":44},"01M6D8H0WMA0PYJXE10H076KB3","Skill Beacon","skillbeacon metadata for scoped skill discovery.","https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden\u002Fblob\u002Fmain\u002Ftests\u002Fdiscovery-repo\u002F.agents\u002Fskills\u002Fskillbeacon\u002FSKILL.md",[134],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,136,137,138,139],"beacon","discovery","skill discovery","metadata",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":44},"01M6D8GXTTDAG9V9M5W1QCWSCK","Build Beacon","buildbeacon metadata for scoped skill discovery.","https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden\u002Fblob\u002Fmain\u002Ftests\u002Fdiscovery-repo\u002F.agents\u002Fskills\u002Fimplement\u002FSKILL.md",[],[136,147,142,138,139,137],"build",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":157,"publishedAt":44},"01M6D8GSWPXC04681NY3XA9BKB","description-frontmatter-authoring","Create or revise Markdown `description` frontmatter so `docgarden match` routes agents to the right repository documents. Use when adding a new routed Markdown document, updating existing frontmatter, fixing noisy or missing match results, tuning skills or docs discovery, or making descriptions more query-aligned without loading document bodies.","https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden\u002Fblob\u002Fmain\u002Fskills\u002Fdescription-frontmatter-authoring\u002FSKILL.md",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",[158,159,160,161,162,163,164,137,165,166,38,167,168,169],"authoring","description frontmatter authoring","docs","documents","create","repository","tuning","markdown","results","document","query","revise",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":44},"01M6D8GPRP006YE31GRYKDRYCP","planner-execplan","Create, update, revise, reopen, or rescope a plan or ExecPlan using `PLANS.md`. Use when an agent needs to create a plan, plan a change, update the plan with new requirements, or rewrite an active ExecPlan.","https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fplanner-execplan\u002FSKILL.md",[],[177,178,169,179,180,162,181,182,38,183,184],"planner execplan","planner","plans","change","update","plan","active","requirements",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":44},"01M6D8GKJJ1867WVATETQF36AR","generator-execplan","Implement from an active plan or ExecPlan while keeping it up to date. Use when an agent needs to implement the active plan, continue plan-driven work, resume the current plan, or carry out an existing ExecPlan.","https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fgenerator-execplan\u002FSKILL.md",[],[192,193,194,182,195,38,196,197,183],"generator execplan","work","implement","continue","up","resume",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":207,"publishedAt":44},"01M6D8GG5PKA3X8VAS35CRWHKH","evaluator-execplan","Review the current branch, PR, or worktree against the plan or ExecPlan and record findings. Use when an agent needs a code review with findings for changes associated with an active plan.","https:\u002F\u002Fgithub.com\u002Fjesse-black\u002Fdocgarden\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fevaluator-execplan\u002FSKILL.md",[204],{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",[208,209,210,211,212,182,213,38,214,183,215],"evaluator execplan","review","pr","code","worktree","branch","record","code review"]