[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SCG4FZJT6BGJRDCZHZ1SN":3,"skill-same:01M71SCG4FZJT6BGJRDCZHZ1SN":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":29,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M71SCG4FZJT6BGJRDCZHZ1SN","tdd",null,"Test-driven development with the red-green-refactor loop","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\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Ftdd\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[5,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"refactor","test","with","pin","use","tests","for","development","bugs","integration tests","refactor loop","features","audit","when","loop","red-green-refactor","green","test-driven","test-first","2026-11-10 13:02:02",false,"---\nname: tdd\ndescription: Test-driven development with the red-green-refactor loop\nwhen_to_use: Use when building features or fixing bugs via TDD, requesting integration tests, or asking for test-first development.\nlicense: MIT\nmetadata:\n  source: Derived from https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills (audit pin 5beb35b)\n---\n\n# Test-Driven Development\n\nTDD is the red → green → refactor loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the named anti-patterns, and the rules of the loop. This is orc iron rule #2 — the failing test comes before the production code, every cycle.\n\nWhen exploring the codebase, use the project's domain glossary (and `GLOSSARY.md` if it exists) so test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.\n\n## What a good test is\n\nTests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — \"user can checkout with valid cart\" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.\n\nSee [references\u002Ftests.md](references\u002Ftests.md) for good\u002Fbad examples and [references\u002Fmocking.md](references\u002Fmocking.md) for mocking guidelines.\n\n## Seams — where tests go\n\nA **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside.\n\n**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything — agreeing the seams up front is how testing effort lands on critical paths and complex logic instead of every possible edge case.\n\nAsk: \"What should the public interface look like, and which seams should we test?\" Give each proposed seam a one-line note on what it catches and what it misses — the user is choosing where testing effort lands, so show them the trade.\n\nWhen the shape of the interface is itself in question — how deep the module is, where the seam belongs — consult `orc-codebase-design` for the module\u002Finterface\u002Fdepth\u002Fseam vocabulary, plus [references\u002Fdeep-modules.md](references\u002Fdeep-modules.md) (small interface, deep implementation) and [references\u002Finterface-design.md](references\u002Finterface-design.md) (designing for testability).\n\n## Anti-patterns\n\n- **Implementation-coupled** — mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.\n- **Tautological** — the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth — a known-good literal, a worked example, the spec.\n- **Horizontal slicing** — writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead — one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.\n\n```\nWRONG (horizontal):          RIGHT (vertical):\n  RED:   test1..test5          RED→GREEN: test1→impl1\n  GREEN: impl1..impl5          RED→GREEN: test2→impl2\n                               ...\n```\n\n## Workflow\n\n### 1. Plan\n\nBefore writing any code:\n\n- [ ] Confirm with the user what interface changes are needed\n- [ ] Confirm the seams under test and which behaviors matter most (prioritize)\n- [ ] List the behaviors to test (not implementation steps)\n- [ ] Get user approval on the plan\n\n### 2. Tracer bullet\n\nWrite ONE test that confirms ONE thing about the system. RED: it fails. GREEN: minimal code to pass. This proves the path works end-to-end.\n\n### 3. Incremental loop\n\nFor each remaining behavior: write the next test → watch it fail → minimal code to pass. Rules:\n\n- **Red before green.** Write the failing test first, then only enough code to pass it.\n- **One slice at a time.** One seam, one test, one minimal implementation per cycle.\n- Don't anticipate future tests or add speculative features.\n\n### 4. Refactor\n\nAfter the suite is green, look for [refactor candidates](references\u002Frefactoring.md): extract duplication, deepen modules, apply what the new code reveals about existing code. Run the tests after each refactor step. **Never refactor while RED.**\n\n## Checklist per cycle\n\n```\n[ ] Test written at a pre-agreed seam\n[ ] Test describes behavior, not implementation\n[ ] Test uses public interface only\n[ ] Test would survive internal refactor\n[ ] Expected values from an independent source of truth\n[ ] Code is minimal for this test\n[ ] No speculative features added\n```\n\n## Rejected framings\n\n- **\"Refactoring is not part of the loop\"** (upstream mattpocock\u002Fskills tdd) — evaluated and REJECTED. Upstream defers refactoring to the review stage; orc keeps it as step 4 of the cycle because the orc-implementer slice loop (step 8: refactor if the green code is ugly, re-run the suite) depends on the refactor step running against a green suite before the per-slice commit. Future audits do not re-propose removing it.\n","# Test-Driven Development\n\nTDD is the red → green → refactor loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the named anti-patterns, and the rules of the loop. This is orc iron rule #2 — the failing test comes before the production code, every cycle.\n\nWhen exploring the codebase, use the project's domain glossary (and `GLOSSARY.md` if it exists) so test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.\n\n## What a good test is\n\nTests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification — \"user can checkout with valid cart\" tells you exactly what capability exists — and survives refactors because it doesn't care about internal structure.\n\nSee [references\u002Ftests.md](references\u002Ftests.md) for good\u002Fbad examples and [references\u002Fmocking.md](references\u002Fmocking.md) for mocking guidelines.\n\n## Seams — where tests go\n\nA **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside.\n\n**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything — agreeing the seams up front is how testing effort lands on critical paths and complex logic instead of every possible edge case.\n\nAsk: \"What should the public interface look like, and which seams should we test?\" Give each proposed seam a one-line note on what it catches and what it misses — the user is choosing where testing effort lands, so show them the trade.\n\nWhen the shape of the interface is itself in question — how deep the module is, where the seam belongs — consult `orc-codebase-design` for the module\u002Finterface\u002Fdepth\u002Fseam vocabulary, plus [references\u002Fdeep-modules.md](references\u002Fdeep-modules.md) (small interface, deep implementation) and [references\u002Finterface-design.md](references\u002Finterface-design.md) (designing for testability).\n\n## Anti-patterns\n\n- **Implementation-coupled** — mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.\n- **Tautological** — the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth — a known-good literal, a worked example, the spec.\n- **Horizontal slicing** — writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead — one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.\n\n```\nWRONG (horizontal):          RIGHT (vertical):\n  RED:   test1..test5          RED→GREEN: test1→impl1\n  GREEN: impl1..impl5          RED→GREEN: test2→impl2\n                               ...\n```\n\n## Workflow\n\n### 1. Plan\n\nBefore writing any code:\n\n- [ ] Confirm with the user what interface changes are needed\n- [ ] Confirm the seams under test and which behaviors matter most (prioritize)\n- [ ] List the behaviors to test (not implementation steps)\n- [ ] Get user approval on the plan\n\n### 2. Tracer bullet\n\nWrite ONE test that confirms ONE thing about the system. RED: it fails. GREEN: minimal code to pass. This proves the path works end-to-end.\n\n### 3. Incremental loop\n\nFor each remaining behavior: write the next test → watch it fail → minimal code to pass. Rules:\n\n- **Red before green.** Write the failing test first, then only enough code to pass it.\n- **One slice at a time.** One seam, one test, one minimal implementation per cycle.\n- Don't anticipate future tests or add speculative features.\n\n### 4. Refactor\n\nAfter the suite is green, look for [refactor candidates](references\u002Frefactoring.md): extract duplication, deepen modules, apply what the new code reveals about existing code. Run the tests after each refactor step. **Never refactor while RED.**\n\n## Checklist per cycle\n\n```\n[ ] Test written at a pre-agreed seam\n[ ] Test describes behavior, not implementation\n[ ] Test uses public interface only\n[ ] Test would survive internal refactor\n[ ] Expected values from an independent source of truth\n[ ] Code is minimal for this test\n[ ] No speculative features added\n```\n\n## Rejected framings\n\n- **\"Refactoring is not part of the loop\"** (upstream mattpocock\u002Fskills tdd) — evaluated and REJECTED. Upstream defers refactoring to the review stage; orc keeps it as step 4 of the cycle because the orc-implementer slice loop (step 8: refactor if the green code is ugly, re-run the suite) depends on the refactor step running against a green suite before the per-slice commit. Future audits do not re-propose removing it.\n",{"name":5,"license":15,"metadata":54,"description":7,"when_to_use":56},{"source":55},"Derived from https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills (audit pin 5beb35b)","Use when building features or fixing bugs via TDD, requesting integration tests, or asking for test-first development.","main","7522fd7266944e30052204c2f6df287d8b5516be","codex\u002Forc\u002Fcontent\u002Fskills\u002Ftdd",0,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc","https:\u002F\u002Forc.novacstack.com\u002F","https:\u002F\u002Fgithub.com\u002FHigorAlves","higoralves.dev","Software Engineering","2026-11-14 07:24:14",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add HigorAlves\u002Forc --skill tdd",{"tool":73,"command":74},"bunx","bunx skills add HigorAlves\u002Forc --skill tdd",{"tool":76,"command":77},"pnpm","pnpm dlx skills add HigorAlves\u002Forc --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Ftdd\u002FSKILL.md",true,[81,87,91,95,99],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fdeep-modules.md","REFERENCE","参考文档",1239,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Ftdd\u002Freferences\u002Fdeep-modules.md",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Finterface-design.md",653,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Ftdd\u002Freferences\u002Finterface-design.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fmocking.md",1481,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Ftdd\u002Freferences\u002Fmocking.md",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Frefactoring.md",387,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Ftdd\u002Freferences\u002Frefactoring.md",{"path":100,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Ftests.md",2214,"https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Fcodex\u002Forc\u002Fcontent\u002Fskills\u002Ftdd\u002Freferences\u002Ftests.md",[104,138,162,183,205,225],{"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":121,"publishedAt":49},"01M71SW40F9TAAEDKBYYBCM814","writing-plans","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","https:\u002F\u002Fgithub.com\u002FHigorAlves\u002Forc\u002Fblob\u002Fmain\u002Forc\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[110,113,118],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":119,"categoryName":120,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000036","内容创作者",[122,123,124,125,126,127,128,43,129,130,131,132,133,134,135,136,137,36,35,34],"writing","writing plans","plans","engineer","superpowers","implementation plan","files","you","code","tasks","verification","plan","write","steps","context","ZeRO",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":147,"publishedAt":49},"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",[144,145,146],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":119,"categoryName":120,"taxonomyType":116,"taxonomyTypeDesc":117},[148,122,36,149,43,150,151,152,153,154,155,156,34,157,158,159,160,161],"writing for agents","matt pocock","inline","tuning","a skill","layer","doctrine","push","editing","document","github","https","reference","docs",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":169,"publishedAt":49},"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",[168],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[170,171,172,173,174,43,175,176,177,178,34,179,180,181,182],"workspace mode","mode","workspace","mechanics","auto","repos","git","pr","repo","dispatch","auto-detection","detection","parent",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":190,"publishedAt":49},"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",[189],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[185,191,192,193,194,149,43,195,196,197,198,199,200,135,201,202,36,34,203,204],"condition","never","provisioning infrastructure","only","Bash","work","credentials","generate","human","secrets","infrastructure","do","one","interactive",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"publishedAt":49},"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",[],[212,213,214,215,216,149,217,218,219,220,158,159,221,222,223,224],"wait what","wait","project","re","true","pitch","last","say","message","land","it","stop","vocabulary",{"skillNo":226,"name":227,"nameZh":6,"description":228,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":229,"categories":230,"keywords":233,"publishedAt":49},"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",[231,232],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},[227,234,235,236,237,238,122,43,239,240,241,242,243,244,245,246,247,248,35,249],"coverage","unit","testing","testing framework","generated","api","jest","2026","at","scripts","unit testing","antfu","framework","vite","mocking","dev"]