[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PFT3GWZ85VXGS6ZC86SCRT":3,"skill-same:01M6PFT3GWZ85VXGS6ZC86SCRT":74},{"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":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6PFT3GWZ85VXGS6ZC86SCRT","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.","refo\u002Fclaude-dev-helpers","refo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1114116?v=4","01M6PFRE5P2JXK3P8VYTERWA33","Refik ÖNAL","01M6PFRE9XZS4SGHG2NQGJ9AB3",2,"MIT","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\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 `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 `review` skill), not the red → green implementation cycle.\n",{"name":5,"description":7},"main","488e6998e820e577029147aceabcbc69961c43df","plugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Ftdd",0,"https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers","https:\u002F\u002Fgithub.com\u002Frefo","2026-07-02 04:43:45",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add refo\u002Fclaude-dev-helpers --skill tdd",{"tool":56,"command":57},"bunx","bunx skills add refo\u002Fclaude-dev-helpers --skill tdd",{"tool":59,"command":60},"pnpm","pnpm dlx skills add refo\u002Fclaude-dev-helpers --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Ftdd\u002FSKILL.md",true,[64,70],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"mocking.md","REFERENCE","参考文档",1481,"https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Ftdd\u002Fmocking.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"tests.md",2214,"https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fengineering\u002Ftdd\u002Ftests.md",[75,101,117,131,146,156],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":91,"publishedAt":38},"01M6PFW0KDMWH5HGR1GA8K39ZN","writing-great-skills","Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fwriting-great-skills\u002FSKILL.md",[81,86],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[92,93,94,95,96,97,98,99,100],"writing great skills","writing","editing","reference","vocabulary","make","principles","true","for",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":110,"publishedAt":38},"01M6PFVXQ3PVRQ9035VZE9RBBX","teach","Teach the user a new skill or concept, within this workspace.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fteach\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000039","教师与教育",[103,111,112,113,31,114,115,99,116],"new skill","learn","workspace","about","you","concept",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":38},"01M6PFVVJB7E7297GXB809B4J4","handoff","Compact the current conversation into a handoff document for another agent to pick up.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fhandoff\u002FSKILL.md",[],[119,124,125,126,127,99,100,128,129,130],"document","conversation","compact","next","up","session","pick",{"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":137,"publishedAt":38},"01M6PFVS5DF6SM2251R15HR9A9","grilling","Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fgrilling\u002FSKILL.md",[],[133,138,139,37,140,141,31,142,29,143,144,145,114],"trigger","design","plan","before building","interview","grill","stress-test","stress",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":38},"01M6PFVQE56YMR6MXKTYWA2467","grill-me","A relentless interview to sharpen a plan or design.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fproductivity\u002Fgrill-me\u002FSKILL.md",[],[153,143,154,142,139,140,155,99],"me","grill me","sharpen",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":38},"01M6PFVMPQ6PWHRFRW5YYZ4VZF","obsidian-vault","Search, create, and manage notes in the Obsidian vault with wikilinks and index notes. Use when user wants to find, create, or organize notes in Obsidian.","https:\u002F\u002Fgithub.com\u002Frefo\u002Fclaude-dev-helpers\u002Fblob\u002Fmain\u002Fplugins\u002Fmp\u002Fskills\u002Fskills\u002Fpersonal\u002Fobsidian-vault\u002FSKILL.md",[],[163,164,165,166,167,168,169,170,31,29,171,172,173],"obsidian vault","vault","obsidian","notes","create","index","search","find","manage","organize","with"]