[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RAZCZA6EG79A01QGH4G97":3,"skill-same:01M71RAZCZA6EG79A01QGH4G97":101},{"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":16,"sourceHtmlUrl":17,"categories":18,"keywords":24,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":25,"commitSha":55,"skillDirectory":56,"forksCount":14,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M71RAZCZA6EG79A01QGH4G97","tdd",null,"Testing standards and test-driven development. Load before writing any tests, including integration tests, regression tests, and test-first feature or bug work. Use for TDD and red-green-refactor.","giladbarnea\u002F.agents","giladbarnea","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F18548473?v=4","01M71R89FAXE3AVQEXP42Y0JF8","Gilad Barnea","01M71R89G2D97KA1WGQ06GPJ1Q",0,"MIT","https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[19],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[5,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"main","2026","test-first","test-driven","standalone","interface","testing standards","local","green","wed","testing","bug","red-green-refactor","work","regression","refactoring","notes","writing","design","2026-11-10 13:02:02",false,"---\nname: tdd\ndescription: Testing standards and test-driven development. Load before writing any tests, including integration tests, regression tests, and test-first feature or bug work. Use for TDD and red-green-refactor.\nlast_updated: 2026-10-21\norigin:\n  url: https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills\u002Ftree\u002Fmain\u002Fskills\u002Fengineering\u002Ftdd\n  commit: 5beb35b040e3de97e54fa9e386d7e42d15c295c2\n  last_checked: 2026-10-21\n  sync: manual\n  adaptation: Includes local testing rules, standalone interface-design notes, and refactoring after green.\n---\n\n# TDD\n\nUse these standards whenever writing tests. Use the TDD loop below for test-first work.\nRead the project instructions, its `GLOSSARY.md` when present, and relevant architectural decisions before choosing test names and interfaces.\n\n## Prove behavior through public interfaces\n\nTests must verify behavior that users or callers need, not implementation details.\nPrefer integration-style tests through real public interfaces. Tests should survive internal refactors without changes.\nDo not test private methods, mock internal collaborators, assert internal call order, or verify through side channels such as direct database queries.\n\nBase test behavior and expected results on the spec, plan, or an independent worked example.\nDo not derive expectations from the implementation or recompute the same algorithm inside the test.\nA test that passes by construction cannot detect a defect.\n\nMock only at system boundaries, such as external APIs, time, or randomness.\nPrefer a test database over a database mock. Do not mock away the behavior under test.\nRead [test examples](tests.md) and [mocking guidance](mocking.md) for concrete patterns.\n\n## Agree on what the tests must prove\n\nUse the public boundaries and behaviors already agreed in the request, spec, or plan.\nBefore testing at another boundary, confirm it with the user. State what each proposed boundary catches and what it misses.\nFocus on critical paths and complex logic instead of trying to test every possible case.\nFewer meaningful tests are better than many tests that cannot expose defects.\n\nWhen the interface needs design work, consult [interface design](interface-design.md) and [deep modules](deep-modules.md).\n\n## Make failure deliberate and informative\n\nDefine a falsification criterion before writing each test: which bad state must this test detect?\nMake sure a failing test exposes that state, not a broken fixture, missing import, or exception in the test itself.\nRead the failure before changing implementation code. A red caused by the wrong problem proves nothing.\n\nUse assertion messages that show the expected and actual values.\nTests must not fail accidentally while inspecting a result. Keep expected application errors separate from test defects.\nWhen mocking an external boundary, patch its real symbol rather than relying on a brittle hard-coded symbol path.\nSee [assertion and fixture examples](tests.md#make-test-failures-explain-the-behavior).\n\n## Develop test-first in vertical slices\n\nDo not write all tests first and then all implementation.\nBulk tests assume behavior before you understand the code and commit you to an unverified test structure.\n\nFor TDD, work through one behavior at a time:\n\n1. **Red:** Write one test at an agreed public boundary. Run it and verify that it fails for the intended reason.\n2. **Green:** Write only enough implementation to pass that test. Run the test again.\n3. **Refactor:** Only after the tests pass, improve the code within the current scope. Keep behavior unchanged and rerun the tests.\n4. Repeat with the next behavior, using what the previous cycle taught you.\n\nThe first cycle is a tracer bullet that proves one complete path through the system.\nDo not add speculative features or implement behavior for a future test.\nNever refactor while tests fail. Use the [refactor candidates](refactoring.md) after green.\n\nThis local skill keeps refactoring after green. Current upstream TDD assigns refactoring to a separate review skill.\n\n## Check each cycle\n\n- The test describes behavior through a public interface and survives internal refactors.\n- Its expected result has an independent source of truth.\n- Its failure exposes the intended bad state and explains what differed.\n- The implementation is minimal and contains no speculative behavior.\n- The relevant tests pass after implementation and after refactoring.\n","# TDD\n\nUse these standards whenever writing tests. Use the TDD loop below for test-first work.\nRead the project instructions, its `GLOSSARY.md` when present, and relevant architectural decisions before choosing test names and interfaces.\n\n## Prove behavior through public interfaces\n\nTests must verify behavior that users or callers need, not implementation details.\nPrefer integration-style tests through real public interfaces. Tests should survive internal refactors without changes.\nDo not test private methods, mock internal collaborators, assert internal call order, or verify through side channels such as direct database queries.\n\nBase test behavior and expected results on the spec, plan, or an independent worked example.\nDo not derive expectations from the implementation or recompute the same algorithm inside the test.\nA test that passes by construction cannot detect a defect.\n\nMock only at system boundaries, such as external APIs, time, or randomness.\nPrefer a test database over a database mock. Do not mock away the behavior under test.\nRead [test examples](tests.md) and [mocking guidance](mocking.md) for concrete patterns.\n\n## Agree on what the tests must prove\n\nUse the public boundaries and behaviors already agreed in the request, spec, or plan.\nBefore testing at another boundary, confirm it with the user. State what each proposed boundary catches and what it misses.\nFocus on critical paths and complex logic instead of trying to test every possible case.\nFewer meaningful tests are better than many tests that cannot expose defects.\n\nWhen the interface needs design work, consult [interface design](interface-design.md) and [deep modules](deep-modules.md).\n\n## Make failure deliberate and informative\n\nDefine a falsification criterion before writing each test: which bad state must this test detect?\nMake sure a failing test exposes that state, not a broken fixture, missing import, or exception in the test itself.\nRead the failure before changing implementation code. A red caused by the wrong problem proves nothing.\n\nUse assertion messages that show the expected and actual values.\nTests must not fail accidentally while inspecting a result. Keep expected application errors separate from test defects.\nWhen mocking an external boundary, patch its real symbol rather than relying on a brittle hard-coded symbol path.\nSee [assertion and fixture examples](tests.md#make-test-failures-explain-the-behavior).\n\n## Develop test-first in vertical slices\n\nDo not write all tests first and then all implementation.\nBulk tests assume behavior before you understand the code and commit you to an unverified test structure.\n\nFor TDD, work through one behavior at a time:\n\n1. **Red:** Write one test at an agreed public boundary. Run it and verify that it fails for the intended reason.\n2. **Green:** Write only enough implementation to pass that test. Run the test again.\n3. **Refactor:** Only after the tests pass, improve the code within the current scope. Keep behavior unchanged and rerun the tests.\n4. Repeat with the next behavior, using what the previous cycle taught you.\n\nThe first cycle is a tracer bullet that proves one complete path through the system.\nDo not add speculative features or implement behavior for a future test.\nNever refactor while tests fail. Use the [refactor candidates](refactoring.md) after green.\n\nThis local skill keeps refactoring after green. Current upstream TDD assigns refactoring to a separate review skill.\n\n## Check each cycle\n\n- The test describes behavior through a public interface and survives internal refactors.\n- Its expected result has an independent source of truth.\n- Its failure exposes the intended bad state and explains what differed.\n- The implementation is minimal and contains no speculative behavior.\n- The relevant tests pass after implementation and after refactoring.\n",{"name":5,"origin":49,"description":7,"last_updated":54},{"url":50,"sync":51,"commit":52,"adaptation":53,"last_checked":54},"https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills\u002Ftree\u002Fmain\u002Fskills\u002Fengineering\u002Ftdd","manual","5beb35b040e3de97e54fa9e386d7e42d15c295c2","Includes local testing rules, standalone interface-design notes, and refactoring after green.",1792540800000,"316bdb3604851f80ab6326c7a666d9a2cec8d28b","skills\u002Ftdd","https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents","https:\u002F\u002Fgithub.com\u002Fgiladbarnea","https:\u002F\u002Fgilad-barnea.com","2026-11-11 22:44:33",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add giladbarnea\u002F.agents --skill tdd",{"tool":67,"command":68},"bunx","bunx skills add giladbarnea\u002F.agents --skill tdd",{"tool":70,"command":71},"pnpm","pnpm dlx skills add giladbarnea\u002F.agents --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",true,[75,81,85,89,93,97],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"deep-modules.md","REFERENCE","参考文档",1239,"https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Fdeep-modules.md",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"interface-design.md",653,"https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Finterface-design.md",{"path":86,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":16},"LICENSE","许可证",1068,{"path":90,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":91,"sourceHtmlUrl":92},"mocking.md",1481,"https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Fmocking.md",{"path":94,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":95,"sourceHtmlUrl":96},"refactoring.md",387,"https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Frefactoring.md",{"path":98,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":99,"sourceHtmlUrl":100},"tests.md",2817,"https:\u002F\u002Fgithub.com\u002Fgiladbarnea\u002F.agents\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Ftests.md",[]]