[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FC7DZPMX49Y82CFZFXWM05":3,"skill-same:01M6FC7DZPMX49Y82CFZFXWM05":99},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":34,"commitSha":65,"skillDirectory":66,"forksCount":67,"repositoryHtmlUrl":68,"repositoryHomepageUrl":6,"ownerHtmlUrl":69,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":70,"install":71,"resources":84},"01M6FC7DZPMX49Y82CFZFXWM05","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.","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",12,"MIT","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tdd\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[5,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"fix","2026","when","test-first","test-driven","features","codex-cli","coding-agents","fix bugs","tests","green","main","community","red-green-refactor","use","cli","coding","matt pocock","first","refactor","license","code","development","integration tests","test","workflow","codex","safe","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.\ncategory: \"development\"\nrisk: \"safe\"\nsource: \"community\"\nsource_repo: \"mattpocock\u002Fskills\"\nsource_type: \"community\"\ndate_added: \"2026-06-19\"\nauthor: \"Matt Pocock\"\nlicense: \"MIT\"\nlicense_source: \"https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills\u002Fblob\u002Fmain\u002FLICENSE\"\ntags:\n  - engineering\n  - workflow\n  - coding-agents\ntools:\n  - claude-code\n  - codex-cli\n  - cursor\n---\n\n# Test-Driven Development\n\n## When to Use\n\nUse when this workflow matches the user request: Use this skill for its documented workflow.\n\n\n_Source: [mattpocock\u002Fskills](https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills) (MIT)._\n\n## Philosophy\n\n**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.\n\n**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - \"user can checkout with valid cart\" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.\n\n**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.\n\nSee [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.\n\n## Anti-Pattern: Horizontal Slices\n\n**DO NOT write all tests first, then all implementation.** This is \"horizontal slicing\" - treating RED as \"write all tests\" and GREEN as \"write all code.\"\n\nThis produces **crap tests**:\n\n- Tests written in bulk test _imagined_ behavior, not _actual_ behavior\n- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior\n- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine\n- You outrun your headlights, committing to test structure before understanding the implementation\n\n**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.\n\n```\nWRONG (horizontal):\n  RED:   test1, test2, test3, test4, test5\n  GREEN: impl1, impl2, impl3, impl4, impl5\n\nRIGHT (vertical):\n  RED→GREEN: test1→impl1\n  RED→GREEN: test2→impl2\n  RED→GREEN: test3→impl3\n  ...\n```\n\n## Workflow\n\n### 1. Planning\n\nWhen exploring the codebase, read `CONTEXT.md` (if it exists) so that test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.\n\nBefore writing any code:\n\n- [ ] Confirm with user what interface changes are needed\n- [ ] Confirm with user which behaviors to test (prioritize)\n- [ ] Identify opportunities for deep modules (small interface, deep implementation) — run the `\u002Fcodebase-design` skill for the vocabulary and the testability checks\n- [ ] List the behaviors to test (not implementation steps)\n- [ ] Get user approval on the plan\n\nAsk: \"What should the public interface look like? Which behaviors are most important to test?\"\n\n**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.\n\n### 2. Tracer Bullet\n\nWrite ONE test that confirms ONE thing about the system:\n\n```\nRED:   Write test for first behavior → test fails\nGREEN: Write minimal code to pass → test passes\n```\n\nThis is your tracer bullet - proves the path works end-to-end.\n\n### 3. Incremental Loop\n\nFor each remaining behavior:\n\n```\nRED:   Write next test → fails\nGREEN: Minimal code to pass → passes\n```\n\nRules:\n\n- One test at a time\n- Only enough code to pass current test\n- Don't anticipate future tests\n- Keep tests focused on observable behavior\n\n### 4. Refactor\n\nAfter all tests pass, look for [refactor candidates](refactoring.md):\n\n- [ ] Extract duplication\n- [ ] Deepen modules (move complexity behind simple interfaces)\n- [ ] Apply SOLID principles where natural\n- [ ] Consider what new code reveals about existing code\n- [ ] Run tests after each refactor step\n\n**Never refactor while RED.** Get to GREEN first.\n\n## Checklist Per Cycle\n\n```\n[ ] Test describes behavior, not implementation\n[ ] Test uses public interface only\n[ ] Test would survive internal refactor\n[ ] Code is minimal for this test\n[ ] No speculative features added\n```\n\n\n## Limitations\n\n- Requires the upstream tool, account, API key, or local setup when the workflow names one.\n- Does not authorize destructive, production, paid, or external-message actions without explicit user approval.\n- Validate generated artifacts or recommendations against the user's real sources before treating them as final.\n","# Test-Driven Development\n\n## When to Use\n\nUse when this workflow matches the user request: Use this skill for its documented workflow.\n\n\n_Source: [mattpocock\u002Fskills](https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills) (MIT)._\n\n## Philosophy\n\n**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.\n\n**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - \"user can checkout with valid cart\" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.\n\n**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.\n\nSee [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.\n\n## Anti-Pattern: Horizontal Slices\n\n**DO NOT write all tests first, then all implementation.** This is \"horizontal slicing\" - treating RED as \"write all tests\" and GREEN as \"write all code.\"\n\nThis produces **crap tests**:\n\n- Tests written in bulk test _imagined_ behavior, not _actual_ behavior\n- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior\n- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine\n- You outrun your headlights, committing to test structure before understanding the implementation\n\n**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.\n\n```\nWRONG (horizontal):\n  RED:   test1, test2, test3, test4, test5\n  GREEN: impl1, impl2, impl3, impl4, impl5\n\nRIGHT (vertical):\n  RED→GREEN: test1→impl1\n  RED→GREEN: test2→impl2\n  RED→GREEN: test3→impl3\n  ...\n```\n\n## Workflow\n\n### 1. Planning\n\nWhen exploring the codebase, read `CONTEXT.md` (if it exists) so that test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.\n\nBefore writing any code:\n\n- [ ] Confirm with user what interface changes are needed\n- [ ] Confirm with user which behaviors to test (prioritize)\n- [ ] Identify opportunities for deep modules (small interface, deep implementation) — run the `\u002Fcodebase-design` skill for the vocabulary and the testability checks\n- [ ] List the behaviors to test (not implementation steps)\n- [ ] Get user approval on the plan\n\nAsk: \"What should the public interface look like? Which behaviors are most important to test?\"\n\n**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.\n\n### 2. Tracer Bullet\n\nWrite ONE test that confirms ONE thing about the system:\n\n```\nRED:   Write test for first behavior → test fails\nGREEN: Write minimal code to pass → test passes\n```\n\nThis is your tracer bullet - proves the path works end-to-end.\n\n### 3. Incremental Loop\n\nFor each remaining behavior:\n\n```\nRED:   Write next test → fails\nGREEN: Minimal code to pass → passes\n```\n\nRules:\n\n- One test at a time\n- Only enough code to pass current test\n- Don't anticipate future tests\n- Keep tests focused on observable behavior\n\n### 4. Refactor\n\nAfter all tests pass, look for [refactor candidates](refactoring.md):\n\n- [ ] Extract duplication\n- [ ] Deepen modules (move complexity behind simple interfaces)\n- [ ] Apply SOLID principles where natural\n- [ ] Consider what new code reveals about existing code\n- [ ] Run tests after each refactor step\n\n**Never refactor while RED.** Get to GREEN first.\n\n## Checklist Per Cycle\n\n```\n[ ] Test describes behavior, not implementation\n[ ] Test uses public interface only\n[ ] Test would survive internal refactor\n[ ] Code is minimal for this test\n[ ] No speculative features added\n```\n\n\n## Limitations\n\n- Requires the upstream tool, account, API key, or local setup when the workflow names one.\n- Does not authorize destructive, production, paid, or external-message actions without explicit user approval.\n- Validate generated artifacts or recommendations against the user's real sources before treating them as final.\n",{"name":5,"risk":50,"tags":56,"tools":58,"author":61,"source":35,"license":14,"category":45,"date_added":62,"description":7,"source_repo":63,"source_type":35,"license_source":64},[57,48,30],"engineering",[59,29,60],"claude-code","cursor","Matt Pocock","2026-06-19","mattpocock\u002Fskills","https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills\u002Fblob\u002Fmain\u002FLICENSE","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-tdd",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-11 14:20:43",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add boisenoise\u002Fskills-collections --skill tdd",{"tool":77,"command":78},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill tdd",{"tool":80,"command":81},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tdd\u002FSKILL.md",true,[85,91,95],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"mocking.md","REFERENCE","参考文档",1481,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tdd\u002Fmocking.md",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"refactoring.md",387,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tdd\u002Frefactoring.md",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"tests.md",1640,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-tdd\u002Ftests.md",[100,127,150,176,195,218],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":104,"licenseFileUrl":105,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":51},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[109,110,111,112,45,113,114,115,116,117,118,119,120,121,122,123,124,125,126,25,24],"web","access","web access","official","browser","search","data","Tools","read","fetch","only","youtube","free tools","platform","critical","free","cover","normal",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":104,"licenseFileUrl":131,"sourceHtmlUrl":132,"categories":133,"keywords":137,"publishedAt":51},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[129,138,38,139,112,45,43,116,140,141,142,143,37,144,145,123,146,147,148,149,24],"MCP","github","Budget","credentials","team","catalog","call","discover","external tools","with","scoped","blob",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":104,"licenseFileUrl":154,"sourceHtmlUrl":155,"categories":156,"keywords":162,"publishedAt":51},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[157],{"categoryNo":158,"categoryName":159,"taxonomyType":160,"taxonomyTypeDesc":161},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[152,139,112,43,163,164,165,166,167,168,123,169,170,171,147,172,173,174,175,149,129,24],"https","email","enrichment","business","evidence","phone","ranking","post","job description","for","person","candidate","reason",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":104,"licenseFileUrl":180,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":51},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[184,185,186,139,112,43,187,188,163,189,140,190,191,192,167,123,193,194,149,129,24],"growth","rea","rea growth","produce","content","playbook","marketing","analyze","public","observations","company",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":104,"licenseFileUrl":199,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":51},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[203,204,139,205,112,206,43,207,208,209,210,211,123,212,213,214,215,216,217,149],"make","make ugc","research","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":104,"licenseFileUrl":222,"sourceHtmlUrl":223,"categories":224,"keywords":225,"publishedAt":51},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[226,227,228,139,112,43,229,230,166,231,232,123,233,234,235,236,237,238,239,149],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","changes","funding"]