[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P77Y4GT3M1Q4735MN5STFK":3,"skill-same:01M6P77Y4GT3M1Q4735MN5STFK":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":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":14,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M6P77Y4GT3M1Q4735MN5STFK","tdd",null,"Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions \"red-green-refactor\", or wants integration tests.","asushiroo\u002Fdotfiles","asushiroo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F113016352?v=4","01M6P6Z9RW9SDSR9XHPMBAYVE6","asushiro","01M6P6Z9WSWDRXZNZCSB4W5JC2",0,"MIT","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Ftdd\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"red-green-refactor","test-first","test-driven","features","bugs","fix bugs","red","tests","green","build","use","fix","user","first","refactor","integration","development","integration tests","test","2026-11-10 10:12:30",false,"---\nname: tdd\ndescription: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions \"red-green-refactor\", or wants integration tests.\n---\n\n# Test-Driven Development\n\nTDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.\n\nWhen exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain 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 [tests.md](tests.md) for examples and [mocking.md](mocking.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. Tests live at seams, never against internals.\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 the critical paths and complex logic instead of every edge case.\n\nAsk: \"What's the public interface, and which seams should we test?\"\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## Rules of the loop\n\n- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.\n- **One slice at a time.** One seam, one test, one minimal implementation per cycle.\n- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.\n","# Test-Driven Development\n\nTDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.\n\nWhen exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain 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 [tests.md](tests.md) for examples and [mocking.md](mocking.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. Tests live at seams, never against internals.\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 the critical paths and complex logic instead of every edge case.\n\nAsk: \"What's the public interface, and which seams should we test?\"\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## Rules of the loop\n\n- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.\n- **One slice at a time.** One seam, one test, one minimal implementation per cycle.\n- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.\n",{"name":5,"description":7},"main","820a8ecb416e59312ffc2b60c29b66eaf5aa27a4",".codex\u002Fskills\u002Ftdd","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fasushiroo","2026-10-02 15:40:43",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add asushiroo\u002Fdotfiles --skill tdd",{"tool":55,"command":56},"bunx","bunx skills add asushiroo\u002Fdotfiles --skill tdd",{"tool":58,"command":59},"pnpm","pnpm dlx skills add asushiroo\u002Fdotfiles --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Ftdd\u002FSKILL.md",true,[63,69,73],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"agents\u002Fopenai.yaml","REFERENCE","参考文档",87,"https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Ftdd\u002Fagents\u002Fopenai.yaml",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"mocking.md",1481,"https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Ftdd\u002Fmocking.md",{"path":74,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":75,"sourceHtmlUrl":76},"tests.md",2214,"https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Ftdd\u002Ftests.md",[78,102,118,131,145,169],{"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":94,"publishedAt":38},"01M6P7AB02738RGKB9RM8QHCA5","writing-shape","Writing, exploit — shape raw material into an article, paragraph by paragraph.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwriting-shape\u002FSKILL.md",[84,89],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[95,96,97,98,99,100,101],"shape","writing shape","writing","exploit","article","material","true",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":110,"publishedAt":38},"01M6P7A81YB2M6P1V7C0BC5YP9","writing-great-skills","Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwriting-great-skills\u002FSKILL.md",[108,109],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[97,111,112,113,114,115,116,101,117],"writing great skills","editing","reference","vocabulary","make","principles","for",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":126,"publishedAt":38},"01M6P7A57S23PPT7MY9E9E08AB","writing-fragments","Writing, explore — mine raw fragments, no structure yet.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwriting-fragments\u002FSKILL.md",[124,125],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[127,97,128,129,130,101],"writing fragments","mine","explore","structure",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":139,"publishedAt":38},"01M6P7A2S5VH0PPWAJTBBH6987","writing-beats","Writing, exploit — assemble raw material into a journey of beats, grounding each term before a beat leans on it.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwriting-beats\u002FSKILL.md",[137,138],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[97,140,98,101,141,142,100,143,144],"writing beats","grounding","it","journey","assemble",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":38},"01M6P79J16SAK6T4CF0RDN62W6","wizard","Generate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each step, and writing .env files and GitHub Actions secrets.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwizard\u002FSKILL.md",[],[147,152,153,154,155,156,157,158,159,160,161,162,163,164,101,165,166,167,168,97],"transition","party","values","manual","github actions","env","third-party","human","files","migration","interactive","Bash","secrets","actions","state","generate","github",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":38},"01M6P79EMS5ZYR75Z3WJBZGG9P","wayfinder","Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.","https:\u002F\u002Fgithub.com\u002Fasushiroo\u002Fdotfiles\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fwayfinder\u002FSKILL.md",[],[171,176,177,178,179,180,181,182,183,184,101,185,186,187,188,189,190,191,192,193],"tracker","more","issue tracker","tickets","clear","as","shared","time","map","issue","session","one at a time","work","decision","plan","chunk","at","can"]