[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CX7NHQG2YFVPTN4B0KZCBB":3,"skill-same:01M6CX7NHQG2YFVPTN4B0KZCBB":78},{"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":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M6CX7NHQG2YFVPTN4B0KZCBB","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.","MFSoftwareEngineering\u002Fmfse-softwarefactory","MFSoftwareEngineering","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F266699757?v=4","01M6CX712369QYG0GP7SWKJKAY","MFSE","01M6CX716NCX9PV4F3DP4Y2E6F",3,"MIT","https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Ftdd\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35],"test","integration tests","development","integration","refactor","first","user","fix","use","red-green-refactor","build","green","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\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","# Test-Driven Development\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",{"name":5,"description":7},"main","1f4cad1bec73e18ff3c76ad481916b391d48a555","skills\u002Fswe\u002Ftdd",1,"https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory","https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering","https:\u002F\u002Fmicheleferracin.it","MFSE Resources for software engineering","2026-08-25 21:54:40",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add MFSoftwareEngineering\u002Fmfse-softwarefactory --skill tdd",{"tool":56,"command":57},"bunx","bunx skills add MFSoftwareEngineering\u002Fmfse-softwarefactory --skill tdd",{"tool":59,"command":60},"pnpm","pnpm dlx skills add MFSoftwareEngineering\u002Fmfse-softwarefactory --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Ftdd\u002FSKILL.md",true,[64,70,74],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"mocking.md","REFERENCE","参考文档",1481,"https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Ftdd\u002Fmocking.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"refactoring.md",387,"https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Ftdd\u002Frefactoring.md",{"path":75,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":76,"sourceHtmlUrl":77},"tests.md",1640,"https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Ftdd\u002Ftests.md",[79,101,112,127,146,166],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":90,"publishedAt":36},"01M6CX7YHWT41CJKQD6SNXFJV6","to-prd","Turn the current conversation into a PRD and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.","https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Fto-prd\u002FSKILL.md",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[91,92,93,94,95,96,97,98,99,100],"to prd","prd","publish","just","interview","Synthesis","issue","tracker","conversation","project",{"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":107,"publishedAt":36},"01M6CX7W1GG7MGWBJVXYK31KVR","to-issues","Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.","https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Fto-issues\u002FSKILL.md",[],[108,109,92,110,111,97,98,100],"issues","to issues","spec","plan",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":36},"01M6CX7KM38DT59GBJE5CAWJ87","grill-with-docs","A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.","https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Fgrill-with-docs\u002FSKILL.md",[],[119,120,121,111,95,122,123,124,125,126],"grill with docs","docs","grill","glossary","adr","sharpen","go","design",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":36},"01M6CX7GXFJPQW7E9CKAYB3V6A","domain-modeling","Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.","https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fswe\u002Fdomain-modeling\u002FSKILL.md",[],[134,135,100,136,137,138,139,124,140,141,142,30,32,34,143,144,145],"domain","domain modeling","domain model","maintain","another skill","ubiquitous language","pin","model","decision","language","terminology","record",{"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":150,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":156,"publishedAt":36},"01M6CX7D46Q5V7Z61KJ3P460R0","owasp-kubernetes","OWASP Kubernetes Top 10 vulnerability knowledge base for identifying, assessing, and remediating security risks in Kubernetes environments - Brought to you by MFSoftwareEngineering\u002Fmfse-softwarefactory","CC-BY-SA-4.0","https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fowasp-kubernetes\u002FSKILL.md",[153],{"categoryNo":154,"categoryName":155,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[157,158,159,160,161,162,163,164,165,100],"owasp","kubernetes","owasp kubernetes","knowledge","security","https","vulnerability","base","knowledge base",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":179,"publishedAt":36},"01M6CX79NRRSCZ5PWZ8714H8Z3","mfse-user-stories-writing","Create effective User Stories with step-by-step guidance. Use when: drafting new features, documenting requirements, writing acceptance criteria in standard BDD format (Given\u002FWhen\u002FThen). Generates complete, properly formatted User Stories.","https:\u002F\u002Fgithub.com\u002FMFSoftwareEngineering\u002Fmfse-softwarefactory\u002Fblob\u002Fmain\u002Fskills\u002Fmfse-user-stories-writing\u002FSKILL.md",[172,175,176],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},{"categoryNo":177,"categoryName":178,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000036","内容创作者",[180,30,181,182,183,184,185,186,187,32,188,189,190,191],"mfse user stories writing","writing","create","acceptance","format","bdd","write","user story","Story","guidance","acceptance criteria","requirements"]