[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SW40F9TAAEDKBYYBCM814":3,"skill-same:01M71SW40F9TAAEDKBYYBCM814":103},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":68,"ownerDescription":69,"updatedAt":70,"install":71,"resources":84},"01M71SW40F9TAAEDKBYYBCM814","writing-plans",null,"Write a comprehensive implementation plan of bite-sized TDD tasks that an engineer with zero codebase context could execute — exact files, code, tests, and verification steps","HigorAlves\u002Forc","HigorAlves","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11262976?v=4","01M71S79EZEMHZ8PQSV0XQJHYY","Higor Alves","01M71S79FKKTCHCN1EDR8DSTWQ",7,"MIT","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"writing plans","plans","writing","use","tests","for","ZeRO","context","steps","write","plan","verification","tasks","code","you","when","files","implementation plan","superpowers","engineer","2026-11-10 13:02:02",false,"---\nname: writing-plans\ndescription: Write a comprehensive implementation plan of bite-sized TDD tasks that an engineer with zero codebase context could execute — exact files, code, tests, and verification steps\nwhen_to_use: Use when you have a spec or requirements for a multi-step task, before touching code.\nlicense: MIT\nmetadata:\n  author: Jesse Vincent\n  source: Derived from https:\u002F\u002Fgithub.com\u002Fobra\u002Fsuperpowers\n---\n\n# Writing Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the implementation plan.\"\n\n**Context:** Run this in a dedicated worktree (created by the brainstorming skill).\n\n**Save plans to:** `docs\u002Fsuperpowers\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`\n- (User preferences for plan location override this default)\n\n## Scope Check\n\nIf the spec covers multiple independent subsystems, brainstorming splits it into sub-project specs. If it didn't, suggest separate plans — one per subsystem. Each plan produces working, testable software on its own.\n\n## File Structure\n\nBefore defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in. In an existing codebase, follow `orc:code-discovery` to locate the relevant files cheaply — when a Graphify code graph is available, `graphify query`\u002F`path` surfaces which modules a change touches and how they connect, so you map the file list without reading the whole tree; fall back to Glob\u002FGrep otherwise.\n\n- Design units with clear boundaries and well-defined interfaces. Each file has one clear responsibility.\n- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.\n- Files that change together live together. Split by responsibility, not by technical layer.\n- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.\n\nThis structure informs the task decomposition. Each task produces self-contained changes that make sense independently.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## LOC Budget Heuristic\n\nEach task produces a diff small enough to review in one sitting. Target **≤ 300 LOC per task** (additions + deletions, post-exclusion — lockfiles, generated code, snapshots, and migrations don't count). Defer to `orc:pr-size-budget` for the exclusion list and resolution order (env var, per-repo config, default).\n\nAdd an `est_loc: \u003Cint>` field to every task header. Read [LOC-BUDGET.md](references\u002FLOC-BUDGET.md) for the estimate heuristic, the Graphify blast-radius refinement, the **1.5× budget** signal (split further, or mark `ships_as_stack: true`), and the budget-contract rule the implementer escalates on.\n\n## Per-slice concurrency + acceptance annotations (mandatory)\n\nEvery slice header also carries — same vocabulary `orc-jira-architect` emits for Jira tasks, so one contract covers both surfaces:\n\n```markdown\n### Slice 3 — POST \u002Fexport endpoint\n- repo: api                # workspace mode only\n- est_loc: 140\n- touchpoints: src\u002Froutes\u002Fexport.ts, test\u002Fexport.test.ts\n- parallel_group: 2\n- depends_on: [1]\n- acceptance:\n  - POST \u002Fexport returns 202 + a Location header\n  - row-stream test covers a 10k-row report\n```\n\nField semantics (`touchpoints` evidence rule, the `parallel_group` disjointness test, `depends_on`, testable `acceptance`): [TEMPLATE.md](references\u002FTEMPLATE.md), \"Slice header fields\".\n\nOn plan approval, the dispatching command copies these annotations into the `slices.json` ledger (`orc-state slice init`; shape per `orc:state-protocol`) — consumers read the ledger, not the prose.\n\n## Plan Document Header and Task Structure\n\nEvery plan starts with the mandatory header and lays out each task as numbered checkbox steps (failing test → run → implement → run → commit) with exact paths and code. Read [TEMPLATE.md](references\u002FTEMPLATE.md) before writing the plan file.\n\n## No Placeholders\n\nEvery step must contain the actual content an engineer needs. These are **plan failures** — never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate error handling\" \u002F \"add validation\" \u002F \"handle edge cases\"\n- \"Write tests for the above\" (without actual test code)\n- \"Similar to Task N\" (repeat the code — the engineer may be reading tasks out of order)\n- Steps that describe what to do without showing how (code blocks required for code steps)\n- References to types, functions, or methods not defined in any task\n\n## Remember\n- Exact file paths always\n- Complete code in every step — if a step changes code, show the code\n- Exact commands with expected output\n- DRY, YAGNI, TDD, frequent commits\n\n## Self-Review\n\nAfter writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch.\n\n**1. Spec coverage:** Skim each section\u002Frequirement in the spec. Can you point to a task that implements it? List any gaps.\n\n**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the \"No Placeholders\" section above. Fix them.\n\n**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.\n\nIf you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.\n\n## Execution Handoff\n\nAfter saving the plan, offer the execution choice (subagent-driven or inline). Read [HANDOFF.md](references\u002FHANDOFF.md) for the prompt text and the required sub-skill per choice.\n","# Writing Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the implementation plan.\"\n\n**Context:** Run this in a dedicated worktree (created by the brainstorming skill).\n\n**Save plans to:** `docs\u002Fsuperpowers\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`\n- (User preferences for plan location override this default)\n\n## Scope Check\n\nIf the spec covers multiple independent subsystems, brainstorming splits it into sub-project specs. If it didn't, suggest separate plans — one per subsystem. Each plan produces working, testable software on its own.\n\n## File Structure\n\nBefore defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in. In an existing codebase, follow `orc:code-discovery` to locate the relevant files cheaply — when a Graphify code graph is available, `graphify query`\u002F`path` surfaces which modules a change touches and how they connect, so you map the file list without reading the whole tree; fall back to Glob\u002FGrep otherwise.\n\n- Design units with clear boundaries and well-defined interfaces. Each file has one clear responsibility.\n- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.\n- Files that change together live together. Split by responsibility, not by technical layer.\n- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.\n\nThis structure informs the task decomposition. Each task produces self-contained changes that make sense independently.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## LOC Budget Heuristic\n\nEach task produces a diff small enough to review in one sitting. Target **≤ 300 LOC per task** (additions + deletions, post-exclusion — lockfiles, generated code, snapshots, and migrations don't count). Defer to `orc:pr-size-budget` for the exclusion list and resolution order (env var, per-repo config, default).\n\nAdd an `est_loc: \u003Cint>` field to every task header. Read [LOC-BUDGET.md](references\u002FLOC-BUDGET.md) for the estimate heuristic, the Graphify blast-radius refinement, the **1.5× budget** signal (split further, or mark `ships_as_stack: true`), and the budget-contract rule the implementer escalates on.\n\n## Per-slice concurrency + acceptance annotations (mandatory)\n\nEvery slice header also carries — same vocabulary `orc-jira-architect` emits for Jira tasks, so one contract covers both surfaces:\n\n```markdown\n### Slice 3 — POST \u002Fexport endpoint\n- repo: api                # workspace mode only\n- est_loc: 140\n- touchpoints: src\u002Froutes\u002Fexport.ts, test\u002Fexport.test.ts\n- parallel_group: 2\n- depends_on: [1]\n- acceptance:\n  - POST \u002Fexport returns 202 + a Location header\n  - row-stream test covers a 10k-row report\n```\n\nField semantics (`touchpoints` evidence rule, the `parallel_group` disjointness test, `depends_on`, testable `acceptance`): [TEMPLATE.md](references\u002FTEMPLATE.md), \"Slice header fields\".\n\nOn plan approval, the dispatching command copies these annotations into the `slices.json` ledger (`orc-state slice init`; shape per `orc:state-protocol`) — consumers read the ledger, not the prose.\n\n## Plan Document Header and Task Structure\n\nEvery plan starts with the mandatory header and lays out each task as numbered checkbox steps (failing test → run → implement → run → commit) with exact paths and code. Read [TEMPLATE.md](references\u002FTEMPLATE.md) before writing the plan file.\n\n## No Placeholders\n\nEvery step must contain the actual content an engineer needs. These are **plan failures** — never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate error handling\" \u002F \"add validation\" \u002F \"handle edge cases\"\n- \"Write tests for the above\" (without actual test code)\n- \"Similar to Task N\" (repeat the code — the engineer may be reading tasks out of order)\n- Steps that describe what to do without showing how (code blocks required for code steps)\n- References to types, functions, or methods not defined in any task\n\n## Remember\n- Exact file paths always\n- Complete code in every step — if a step changes code, show the code\n- Exact commands with expected output\n- DRY, YAGNI, TDD, frequent commits\n\n## Self-Review\n\nAfter writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch.\n\n**1. Spec coverage:** Skim each section\u002Frequirement in the spec. Can you point to a task that implements it? List any gaps.\n\n**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the \"No Placeholders\" section above. Fix them.\n\n**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.\n\nIf you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.\n\n## Execution Handoff\n\nAfter saving the plan, offer the execution choice (subagent-driven or inline). Read [HANDOFF.md](references\u002FHANDOFF.md) for the prompt text and the required sub-skill per choice.\n",{"name":5,"license":15,"metadata":57,"description":7,"when_to_use":60},{"author":58,"source":59},"Jesse Vincent","Derived from https:\u002F\u002Fgithub.com\u002Fobra\u002Fsuperpowers","Use when you have a spec or requirements for a multi-step task, before touching code.","main","7522fd7266944e30052204c2f6df287d8b5516be","orc\u002Fskills\u002Fwriting-plans",0,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc","https:\u002F\u002Forc.novacstack.com\u002F","https:\u002F\u002Fgithub.com\u002FHigorAlves","higoralves.dev","Software Engineering","2026-11-07 07:26:38",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add HigorAlves\u002Forc --skill writing-plans",{"tool":77,"command":78},"bunx","bunx skills add HigorAlves\u002Forc --skill writing-plans",{"tool":80,"command":81},"pnpm","pnpm dlx skills add HigorAlves\u002Forc --skill writing-plans","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",true,[85,91,95,99],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"plan-document-reviewer-prompt.md","REFERENCE","参考文档",1714,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002Fplan-document-reviewer-prompt.md",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002FHANDOFF.md",855,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002Freferences\u002FHANDOFF.md",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002FLOC-BUDGET.md",1722,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002Freferences\u002FLOC-BUDGET.md",{"path":100,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002FTEMPLATE.md",2497,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002Freferences\u002FTEMPLATE.md",[104,130,151,173,193,220],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":115,"publishedAt":52},"01M71SW15KHE4MHJW9NEXV65X2","writing-for-agents","orc's doctrine layer for writing any document an agent consumes — skills, AGENTS.md\u002FCLAUDE.md, reference docs","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[110,111,114],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},[116,34,37,117,47,118,119,120,121,122,123,124,35,125,126,127,128,129],"writing for agents","matt pocock","inline","tuning","a skill","layer","doctrine","push","editing","document","github","https","reference","docs",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":137,"publishedAt":52},"01M71SVYQKXT743HHHWGHT3G13","workspace-mode","Use when cwd is a parent dir holding multiple sibling git repos — defines repo auto-detection, --repos\u002F--repo\u002F--all-repos\u002F--this-repo precedence, per-repo dispatch, and linked-PR mechanics.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fworkspace-mode\u002FSKILL.md",[136],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[138,139,140,141,142,47,143,144,145,146,35,147,148,149,150],"workspace mode","mode","workspace","mechanics","auto","repos","git","pr","repo","dispatch","auto-detection","detection","parent",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":52},"01M71SVVP3BXS06G9395P2K0RH","wizard","Generate an interactive bash wizard walking a human through work only they can perform — credentials, secrets, one-off migrations","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwizard\u002FSKILL.md",[157],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[153,159,160,161,162,117,47,163,164,165,166,167,168,40,169,170,37,35,171,172],"condition","never","provisioning infrastructure","only","Bash","work","credentials","generate","human","secrets","infrastructure","do","one","interactive",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":52},"01M71SVT4AR6NKAM5B077E7QSJ","wait-what","Stop and re-pitch — the last message did not land; say it again simply, in the project's own vocabulary.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[180,181,182,183,184,117,185,186,187,188,126,127,189,190,191,192],"wait what","wait","project","re","true","pitch","last","say","message","land","it","stop","vocabulary",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":203,"publishedAt":52},"01M71SVQVYRA9QBQ6G8MWR8G6F","vitest","Vitest fast unit testing framework powered by Vite with Jest-compatible API","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fvitest\u002FSKILL.md",[199,202],{"categoryNo":200,"categoryName":201,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[195,204,205,206,207,208,34,47,209,210,211,212,213,214,215,216,217,218,36,219],"coverage","unit","testing","testing framework","generated","api","jest","2026","at","scripts","unit testing","antfu","framework","vite","mocking","dev",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":227,"publishedAt":52},"01M71SVN8FYE8WTM976SESKHNS","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or opening PRs — evidence before assertions. Doctrine skill (preloaded into orc-implementer), not a command — the bundled \u002Fverify covers interactive one-off behavioral checks.","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[226],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},[43,228,229,230,50,47,164,231,232,122,233,234,235,35,236,237,171,172,126,238],"verification before completion","implementer","claim","command","behavioral","evidence","complete","prs","assertions","committing","verify"]