[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HBVNQ1ASFTJTYT47F8M559":3,"skill-same:01M6HBVNQ1ASFTJTYT47F8M559":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":26,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":70},"01M6HBVNQ1ASFTJTYT47F8M559","tdd",null,"Build new behavior test-first using strict Red-Green-Refactor cycles. Use this when you want to drive a new feature or behavior from failing tests before writing the implementation.","SyloRei\u002Fclaude-godmode","SyloRei","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5840195?v=4","01M6HBT6QSK7QM4DTVPNGARNP4","Andrey Prokofev","01M6HBT6WED1MEN8W7JYP412WE",3,"MIT","https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"true","writing","you","red","feature","tests","green","build","implementation","drive","red-green-refactor","use","new feature","behavior","first","refactor","test","2026-11-10 10:12:30",false,"---\nname: tdd\ndescription: \"Build new behavior test-first using strict Red-Green-Refactor cycles. Use this when you want to drive a new feature or behavior from failing tests before writing the implementation.\"\nuser-invocable: true\n---\n\n# Test-Driven Development\n\nImplement features using strict Red-Green-Refactor cycles. Implements the testing protocol in `rules\u002Fgodmode-testing.md`.\n\n---\n\n## Auto Mode\n\nAuto Mode suppresses confirmation prompts, not the clarifying questions that decide what the tests assert. **If a target behavior is genuinely ambiguous — the expected output, an edge case's contract — don't ask blank: lead with the contract you'd assert and invite the override** (e.g. \"I'll assert this edge case returns an empty list rather than throwing — correct me before I write the red test\"), because the tests encode it and guessing bakes the wrong contract into red-green. This is the clarifying rendering of the shared recommendation convention (`godmode:recommend-convention`) defined in `rules\u002Fgodmode-recommend.md`. For low-stakes decomposition choices, use reasonable defaults and surface the behavior list + assumptions inline, then run the cycles. Treat course-corrections as normal input.\n\n---\n\n## The Job\n\nBreak the feature into small behaviors. For each behavior, run one Red-Green-Refactor cycle.\n\n---\n\n## The Cycle\n\n### RED — Write a failing test\n\n- Write ONE test for the next desired behavior\n- Run it. It MUST fail. If it passes, the test is wrong.\n- The test should fail for the RIGHT reason (not syntax\u002Fimport error)\n- Test name: `should [expected behavior] when [condition]`\n\n### GREEN — Make it pass with minimal code\n\n- Write the SIMPLEST code that makes the test pass\n- No optimization, no elegance — just pass\n- Run ALL tests. Every test must pass.\n\n### REFACTOR — Clean up while green\n\n- Remove duplication, improve naming, simplify logic\n- Run tests after EACH refactoring change\n- If any test breaks: revert and try smaller step\n\n---\n\n## Rules\n\n- **NEVER write production code without a failing test first**\n- One test at a time. Don't batch.\n- Commit after each GREEN step (atomic progress)\n- Test behavior, not implementation details\n- Keep tests independent — no shared mutable state\n- Detect and use the project's existing test framework\n- When `.planning\u002FSTANDARDS.md` is present, the code you write must honor it as authoritative project context over the generic defaults where it has spoken (see \"Project Standards Precedence\" in `rules\u002Fgodmode-coding.md`)\n\n---\n\n## Workflow Per Feature\n\n1. List the behaviors to implement (3-7 items typically)\n2. Order from simplest to most complex\n3. For each: RED → GREEN → REFACTOR → COMMIT\n4. After all: run quality gates (from `config\u002Fquality-gates.txt`)\n\n---\n\n## Progress Report\n\nAfter each cycle:\n```\nCycle N: [test name]\n  RED:      Test written, fails as expected\n  GREEN:    [approach taken], all tests pass\n  REFACTOR: [what was cleaned up] (or \"none needed\")\n  Tests:    X passing \u002F X total\n```\n\n---\n\n## Agent Routing\n\n| Step | Agent | Purpose |\n|------|-------|---------|\n| Before first RED | MUST spawn @researcher | Find test framework, utilities, naming conventions, fixtures, and existing test patterns |\n| REFACTOR | Always run `\u002Fverify` (5 parallel review lenses) when >3 files changed | Review refactored code for correctness and adherence to project patterns |\n\n**Rule:** Never explore the codebase inline when @researcher can do it in parallel.\n\n---\n\n## Feeding Back Into the Workflow\n\nAfter the behavior list is generated (end of \"Workflow Per Feature\" step 1), decide how the work re-enters the workflow spine:\n\n- **Run all cycles now (default).** Drive each behavior through RED-GREEN-REFACTOR immediately, committing after each GREEN. Best when the feature is small and well-scoped.\n- **Defer as a work unit.** When the feature is large (4+ behaviors) and deserves its own planning pass, append a work unit to `.planning\u002Fmissions\u002F\u003Cmission_id>\u002FROADMAP.md` describing the feature and its behaviors, then pick it up with `\u002Fbrief N`. The brief captures the why + what, `\u002Fplan N` breaks it down into the same behavior list, and `\u002Fbuild N` drives the cycles.\n\nIn Auto Mode, run all cycles now unless the feature clearly needs its own planning pass — then append a work unit and say so inline.\n\n**Appended work-unit note (for `.planning\u002Fmissions\u002F\u003Cmission_id>\u002FROADMAP.md`):**\n\n```\n- TDD: [feature name] — N behaviors, each one RED-GREEN-REFACTOR cycle.\n  Behaviors: [short list]. Drive test-first; quality gates per cycle.\n```\n\n---\n\n## Output\n\n\u003C!-- Output follows the in-skill output convention: godmode:output-convention — see rules\u002Fgodmode-output.md -->\n\nThe Progress Report above narrates each Red-Green-Refactor cycle as it runs; close the whole run with one consolidated result block. It leads with the terminal state, summarizes the cycles, and names one next move:\n\n- **Status** — all behaviors driven test-first to green, or the remaining work deferred as a work unit.\n- **Cycles** — the behaviors implemented, each one a completed Red→Green→Refactor cycle.\n- **Tests** — the passing\u002Ftotal count and the files changed.\n- **Gates** — the quality-gate results (all ✓).\n- **Next** — the single onward pointer:\n\n> \"Implemented [N] behaviors test-first; [X]\u002F[X] tests pass and all quality gates are green. Run `\u002Fship` to take the feature to a PR.\"\n\nWhen the remaining behaviors are deferred instead of driven now, the next-step names the work-unit handoff:\n\n> \"Drove [N] behaviors; appended the rest as a work unit to `.planning\u002Fmissions\u002F\u003Cmission_id>\u002FROADMAP.md`. Run `\u002Fbrief N` to plan it.\"\n\n---\n\n## Related\n\n- **@test-writer** — for adding coverage to existing code (not TDD)\n- **\u002Frefactor** — for refactoring existing code without adding features\n- **\u002Fdebug** — if a test reveals a bug, switch to debugging protocol\n\n**Spine:** decompose into behaviors, then either run the cycles now (`\u002Fship`) or append a work unit to `.planning\u002Fmissions\u002F\u003Cmission_id>\u002FROADMAP.md` and resume the spine at `\u002Fbrief N`.\n","# Test-Driven Development\n\nImplement features using strict Red-Green-Refactor cycles. Implements the testing protocol in `rules\u002Fgodmode-testing.md`.\n\n---\n\n## Auto Mode\n\nAuto Mode suppresses confirmation prompts, not the clarifying questions that decide what the tests assert. **If a target behavior is genuinely ambiguous — the expected output, an edge case's contract — don't ask blank: lead with the contract you'd assert and invite the override** (e.g. \"I'll assert this edge case returns an empty list rather than throwing — correct me before I write the red test\"), because the tests encode it and guessing bakes the wrong contract into red-green. This is the clarifying rendering of the shared recommendation convention (`godmode:recommend-convention`) defined in `rules\u002Fgodmode-recommend.md`. For low-stakes decomposition choices, use reasonable defaults and surface the behavior list + assumptions inline, then run the cycles. Treat course-corrections as normal input.\n\n---\n\n## The Job\n\nBreak the feature into small behaviors. For each behavior, run one Red-Green-Refactor cycle.\n\n---\n\n## The Cycle\n\n### RED — Write a failing test\n\n- Write ONE test for the next desired behavior\n- Run it. It MUST fail. If it passes, the test is wrong.\n- The test should fail for the RIGHT reason (not syntax\u002Fimport error)\n- Test name: `should [expected behavior] when [condition]`\n\n### GREEN — Make it pass with minimal code\n\n- Write the SIMPLEST code that makes the test pass\n- No optimization, no elegance — just pass\n- Run ALL tests. Every test must pass.\n\n### REFACTOR — Clean up while green\n\n- Remove duplication, improve naming, simplify logic\n- Run tests after EACH refactoring change\n- If any test breaks: revert and try smaller step\n\n---\n\n## Rules\n\n- **NEVER write production code without a failing test first**\n- One test at a time. Don't batch.\n- Commit after each GREEN step (atomic progress)\n- Test behavior, not implementation details\n- Keep tests independent — no shared mutable state\n- Detect and use the project's existing test framework\n- When `.planning\u002FSTANDARDS.md` is present, the code you write must honor it as authoritative project context over the generic defaults where it has spoken (see \"Project Standards Precedence\" in `rules\u002Fgodmode-coding.md`)\n\n---\n\n## Workflow Per Feature\n\n1. List the behaviors to implement (3-7 items typically)\n2. Order from simplest to most complex\n3. For each: RED → GREEN → REFACTOR → COMMIT\n4. After all: run quality gates (from `config\u002Fquality-gates.txt`)\n\n---\n\n## Progress Report\n\nAfter each cycle:\n```\nCycle N: [test name]\n  RED:      Test written, fails as expected\n  GREEN:    [approach taken], all tests pass\n  REFACTOR: [what was cleaned up] (or \"none needed\")\n  Tests:    X passing \u002F X total\n```\n\n---\n\n## Agent Routing\n\n| Step | Agent | Purpose |\n|------|-------|---------|\n| Before first RED | MUST spawn @researcher | Find test framework, utilities, naming conventions, fixtures, and existing test patterns |\n| REFACTOR | Always run `\u002Fverify` (5 parallel review lenses) when >3 files changed | Review refactored code for correctness and adherence to project patterns |\n\n**Rule:** Never explore the codebase inline when @researcher can do it in parallel.\n\n---\n\n## Feeding Back Into the Workflow\n\nAfter the behavior list is generated (end of \"Workflow Per Feature\" step 1), decide how the work re-enters the workflow spine:\n\n- **Run all cycles now (default).** Drive each behavior through RED-GREEN-REFACTOR immediately, committing after each GREEN. Best when the feature is small and well-scoped.\n- **Defer as a work unit.** When the feature is large (4+ behaviors) and deserves its own planning pass, append a work unit to `.planning\u002Fmissions\u002F\u003Cmission_id>\u002FROADMAP.md` describing the feature and its behaviors, then pick it up with `\u002Fbrief N`. The brief captures the why + what, `\u002Fplan N` breaks it down into the same behavior list, and `\u002Fbuild N` drives the cycles.\n\nIn Auto Mode, run all cycles now unless the feature clearly needs its own planning pass — then append a work unit and say so inline.\n\n**Appended work-unit note (for `.planning\u002Fmissions\u002F\u003Cmission_id>\u002FROADMAP.md`):**\n\n```\n- TDD: [feature name] — N behaviors, each one RED-GREEN-REFACTOR cycle.\n  Behaviors: [short list]. Drive test-first; quality gates per cycle.\n```\n\n---\n\n## Output\n\n\u003C!-- Output follows the in-skill output convention: godmode:output-convention — see rules\u002Fgodmode-output.md -->\n\nThe Progress Report above narrates each Red-Green-Refactor cycle as it runs; close the whole run with one consolidated result block. It leads with the terminal state, summarizes the cycles, and names one next move:\n\n- **Status** — all behaviors driven test-first to green, or the remaining work deferred as a work unit.\n- **Cycles** — the behaviors implemented, each one a completed Red→Green→Refactor cycle.\n- **Tests** — the passing\u002Ftotal count and the files changed.\n- **Gates** — the quality-gate results (all ✓).\n- **Next** — the single onward pointer:\n\n> \"Implemented [N] behaviors test-first; [X]\u002F[X] tests pass and all quality gates are green. Run `\u002Fship` to take the feature to a PR.\"\n\nWhen the remaining behaviors are deferred instead of driven now, the next-step names the work-unit handoff:\n\n> \"Drove [N] behaviors; appended the rest as a work unit to `.planning\u002Fmissions\u002F\u003Cmission_id>\u002FROADMAP.md`. Run `\u002Fbrief N` to plan it.\"\n\n---\n\n## Related\n\n- **@test-writer** — for adding coverage to existing code (not TDD)\n- **\u002Frefactor** — for refactoring existing code without adding features\n- **\u002Fdebug** — if a test reveals a bug, switch to debugging protocol\n\n**Spine:** decompose into behaviors, then either run the cycles now (`\u002Fship`) or append a work unit to `.planning\u002Fmissions\u002F\u003Cmission_id>\u002FROADMAP.md` and resume the spine at `\u002Fbrief N`.\n",{"name":5,"description":7,"user-invocable":49},true,"main","717a1f3af996804502df0047840b6c74a1d464c5","skills\u002Ftdd",0,"https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode","https:\u002F\u002Fgithub.com\u002FSyloRei","Nya? Kawai? Desu?","2026-06-08 16:03:07",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":49},[60,63,66],{"tool":61,"command":62},"npx","npx skills add SyloRei\u002Fclaude-godmode --skill tdd",{"tool":64,"command":65},"bunx","bunx skills add SyloRei\u002Fclaude-godmode --skill tdd",{"tool":67,"command":68},"pnpm","pnpm dlx skills add SyloRei\u002Fclaude-godmode --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"scripts\u002FREADME.md","SCRIPT","脚本",1169,"https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Fscripts\u002FREADME.md",[78,86,111,132,151,176],{"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":84,"publishedAt":44},"01M6HBW3WEVBXANCRWF5YK5BYC","{{name=null}=null}","{{description=null}=null}","https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Ftemplates\u002Fskill\u002FSKILL.md",[],[80,85,27],"name",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":44},"01M6HBVZ86GN3TGGFSJ4XM9C5Q","verify","Check a built unit goal-backward: classify every brief acceptance criterion COVERED \u002F PARTIAL \u002F MISSING with concrete evidence, so you know what is truly done. Use when: verify N, check whether unit N is done, confirm the goals for roadmap unit N are met.","https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Fskills\u002Fverify\u002FSKILL.md",[],[88,93,94,95,29,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110],"run","git","godmode","ShellCheck","unit","scripts","classify","done","show","log","goal","roadmap","coverage","read","model","Bash","brief","acceptance",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":44},"01M6HBVTDPNPD88ZWXT4T5M8EA","triage","Respond to a production incident, outage, or regression in the wild: establish the timeline, assess blast radius, and reconstruct what happened with cited evidence. Use this when something is failing in production and you need to understand it before fixing it.","https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002FSKILL.md",[],[113,118,119,27,29,120,121,122,123,124,125,126,38,127,128,129,130,131],"evidence","wild","with","understand","it","respond","assess","production incident","incident","regression","radius","timeline","Production","blast radius",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":44},"01M6HBVH8GX9JCMS5432JZVTMN","ship","Run every canonical quality gate, push the branch, and open a pull request — release in one command. Use when: ship it, ready to ship, create the PR, push and open a PR.","https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Fskills\u002Fship\u002FSKILL.md",[],[134,139,98,140,95,94,141,106,142,143,107,108,144,145,146,147,93,148,149,150],"canonical","ship it","ready","command","branch","open","push","pull","release","create","quality gate","pr",{"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":162,"publishedAt":44},"01M6HBVB6SVSMQPXBMWEWQ4J5M","refine","Mid-mission gap analysis: read the active mission's roadmap and briefs, surface what's missing or underspecified, converge on one gap, and append a NEW numbered work unit plus its full brief — strictly additive. Use when: refine, what are we missing, find gaps in the current mission, add the next unit. Never edits an existing brief or roadmap unit in place — that is \u002Fbrief N's job.","https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Fskills\u002Frefine\u002FSKILL.md",[157],{"categoryNo":158,"categoryName":159,"taxonomyType":160,"taxonomyTypeDesc":161},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[153,163,164,165,95,104,166,167,168,169,106,170,108,171,109,172,173,174,97,175],"work","active","next","never","append","edit","write","full","analysis","mission","converge","briefs","add",{"skillNo":177,"name":42,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":186,"publishedAt":44},"01M6HBV7SGBH14T5K2336RYZWW","Improve code structure without changing behavior, verifying with tests at every step. Use this when you want to restructure, extract, rename, or simplify existing code that already works.","https:\u002F\u002Fgithub.com\u002FSyloRei\u002Fclaude-godmode\u002Fblob\u002Fmain\u002Fskills\u002Frefactor\u002FSKILL.md",[181,182,183],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":184,"categoryName":185,"taxonomyType":160,"taxonomyTypeDesc":161},"01JBSEEDCAT000000000000030","开发工程师",[42,40,187,188,189,38,190,191,27,29,120,32,192,193,194],"code","simplify","improve","Existing","at","structure","extract","rename"]