[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7AB9F71THGD2824Y3PAMVW9":3,"skill-same:01M7AB9F71THGD2824Y3PAMVW9":62},{"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":15,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":13,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":29,"install":30,"resources":43},"01M7AB9F71THGD2824Y3PAMVW9","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.","BoldFaceType\u002Fskill-core","BoldFaceType","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F144050236?v=4","01M7AB6W37HGDQHMGD894TAMM7","01M7AB6W410VBMTHFK1EZ08CCC",0,"MIT","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftdd\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftdd\u002FSKILL.md",[],[],"2026-11-15 14:19:17",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\nWhen the shape of that interface is itself in question — how deep the module is, where the seam belongs, what the interface should expose — use the `\u002Fcodebase-design` skill for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.\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\nWhen the shape of that interface is itself in question — how deep the module is, where the seam belongs, what the interface should expose — use the `\u002Fcodebase-design` skill for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.\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","420d55ce2910ebd06b3f62a6900a652ab7d5cab9",".agents\u002Fskills\u002Ftdd","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core","https:\u002F\u002Fgithub.com\u002FBoldFaceType","2026-10-17 05:08:53",{"source":8,"skillName":5,"commands":31,"prompt":41,"zipAvailable":42},[32,35,38],{"tool":33,"command":34},"npx","npx skills add BoldFaceType\u002Fskill-core --skill tdd",{"tool":36,"command":37},"bunx","bunx skills add BoldFaceType\u002Fskill-core --skill tdd",{"tool":39,"command":40},"pnpm","pnpm dlx skills add BoldFaceType\u002Fskill-core --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftdd\u002FSKILL.md",true,[44,50,54,58],{"path":45,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":48,"sourceHtmlUrl":49},"agents\u002Fopenai.yaml","REFERENCE","参考文档",87,"https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftdd\u002Fagents\u002Fopenai.yaml",{"path":51,"resourceType":51,"resourceTypeDesc":52,"sizeBytes":53,"sourceHtmlUrl":15},"LICENSE","许可证",1068,{"path":55,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":56,"sourceHtmlUrl":57},"mocking.md",1481,"https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftdd\u002Fmocking.md",{"path":59,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":60,"sourceHtmlUrl":61},"tests.md",2214,"https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftdd\u002Ftests.md",[63,71,79,87,96,104],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":67,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M7AB9RWAT323SREG0TZEF4TB","to-tickets","Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker — edges as text in one file per ticket locally, or native blocking links on a real tracker.","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-tickets\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-tickets\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":75,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M7AB9MGT2J78YV31G9977C3C","to-spec","Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-spec\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-spec\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":83,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":19},"01M7AB9HXZD0PAW5HVZ4DP5SJV","to-questionnaire","Turn a decision you can't fully answer into a questionnaire for someone else to fill in.","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-questionnaire\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fto-questionnaire\u002FSKILL.md",[],[],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":91,"licenseFileUrl":92,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"01M7AB9CDPPWFSAMTK9RVWX1KS","task-management","Simple task management using a shared TASKS.md file. Reference this when the user asks about their tasks, wants to add\u002Fcomplete tasks, or needs help tracking commitments.","Apache-2.0","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftask-management\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftask-management\u002FSKILL.md",[],[],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":100,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":19},"01M7AB976Q5C106DWG3N1MMC6Z","skillopt-sleep","Use when the user wants Codex to self-improve from past usage, asks about a nightly\u002Foffline 'sleep' or 'dream' cycle, wants Codex to review past sessions, learn preferences, consolidate memory\u002Fskills, run dry-run\u002Frun\u002Fadopt\u002Fstatus for SkillOpt-Sleep, or schedule background self-optimization. Drives the skillopt_sleep engine: harvest past sessions -> mine recurring tasks -> replay through a selected backend -> consolidate validated memory + skills behind a held-out gate.","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fskillopt-sleep\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fskillopt-sleep\u002FSKILL.md",[],[],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":91,"licenseFileUrl":108,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":19},"01M7AB900FT194NGFAQV5TR4D0","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fskill-creator\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FBoldFaceType\u002Fskill-core\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fskill-creator\u002FSKILL.md",[],[]]