[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7AAPZSMP4Y7FSGEN9S910S5":3,"skill-same:01M7AAPZSMP4Y7FSGEN9S910S5":54},{"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":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":13,"repositoryHtmlUrl":26,"repositoryHomepageUrl":27,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":29,"install":30,"resources":43},"01M7AAPZSMP4Y7FSGEN9S910S5","tdd",null,"Test-driven development. Use when the user wants a red-green development loop or integration tests.","joeloverbeck\u002Fskill-evidence","joeloverbeck","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F120873?v=4","01M758KCBJ0GWAPGN74C9NJF8T","01M7AAJ49JAQNVPTMQSWVB57TY",0,"MIT","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_3e39da1f-a737-4029-bd88-f710519fe3de\u002Farms\u002Fcurrent\u002Fmethod\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: tdd\ndescription: Test-driven development. Use when the user wants a red-green development loop or 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\nBefore testing a public invariant or choosing a golden fixture, read [tests.md](tests.md) for the required coverage and sensitivity checks; see [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 each seam under test and its authority. A seam ratified in an authoritative PRD, live issue, ADR, or explicit user decision is already agreed; ask the user only when the seam is absent or ambiguous. 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\nWhen those sources do not settle the seam, ask: \"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 selector or explicitly named parameterized\u002Fsubtest case, one minimal implementation per cycle.\n- **Retain the cycle evidence.** For each behavior, keep one TDD evidence row: seam authority; test file and exact test selector or explicitly named parameterized\u002Fsubtest case; observed public entry point; red command and intended plus observed failure; green command and result. Every command position replays on its own — a complete runnable command, or a stable key defined in the same evidence section and referenced with its argument. The green command is a position of its own even when it repeats the red; a back-reference such as \"same command\" or \"same suite\" is not a command or key. This skill owns that evidence.\n- **Use an authoritative verifier when it already supplies red.** If an authoritative PRD, live issue, ADR, or explicit user decision supplies an already-failing public verifier, confirm that its observed failure is the intended failure for the authorized criterion; that failure may then serve as red, without adding a duplicative test only to satisfy chronology. Keep one focused case per cycle whenever the verifier supports focus. When the verifier is indivisible and reports a finite named failure set that forms one atomic acceptance criterion, one aggregate cycle is allowed: record the verifier path and complete command, fixture or input identity, seam authority, the exact intended and observed red set, the minimal implementation, and the final green result. In this branch, the evidence row may name the verifier and input identity instead of a test file and selector, and pre-review reconciliation records `no changed tests; existing verifier evidence` and compares the existing-verifier evidence identities with their reconciliation identities in both directions.\n- **Reconcile tests to seams before review.** Before `\u002Fcode-review`, derive and retain a changed-test inventory from the scoped diff using the repository's native test structure. Keep one reconciliation row per changed test selector or explicitly named parameterized\u002Fsubtest case: test file; exact selector or case identity; observed public entry point; seam authority; TDD evidence row. File- or class-level summaries do not satisfy this gate. Compare the inventory identities with the reconciliation identities in both directions and require both differences to be empty. If a test enters through a module, helper, mutable global, side channel, or other boundary the authority did not ratify for that behavior, ratify that seam or rewrite the test at the agreed public boundary. This gate concerns the public behavior each row claims: a private-invariant test cannot substitute for that public-behavior proof. Reconcile every evidence row before `\u002Fcode-review` only after this coverage check passes.\n- **Review repairs and refactoring.** When `\u002Fcode-review` finds missing or incorrect observable behavior, `\u002Fimplement` must re-enter one new red → green slice. For each actionable finding that `\u002Fcode-review` marks `TDD re-entry required: yes`, append one evidence row keyed by review pass, axis, and finding, run the focused red, then apply only enough production repair to reach green; consume those routing fields as supplied rather than reclassifying the finding here. Never rewrite or extend an earlier row to absorb a later finding. If the same test selector is reused, the new row must name the distinct new parameterized\u002Fsubtest case and its focused red command. Before final handoff, compare the applicable finding identities in `\u002Fcode-review`'s `Findings fixed during review` ledger with the appended review-reentry row identities in both directions and require both differences to be empty. A repair that only refactors without changing behavior stays outside the red → green loop. Hand the reconciled, scoped committed change back to `\u002Fcode-review`; that skill owns finding classification and the two-axis review, `\u002Fimplement` owns the repair loop, and this skill owns TDD evidence.\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\nBefore testing a public invariant or choosing a golden fixture, read [tests.md](tests.md) for the required coverage and sensitivity checks; see [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 each seam under test and its authority. A seam ratified in an authoritative PRD, live issue, ADR, or explicit user decision is already agreed; ask the user only when the seam is absent or ambiguous. 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\nWhen those sources do not settle the seam, ask: \"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 selector or explicitly named parameterized\u002Fsubtest case, one minimal implementation per cycle.\n- **Retain the cycle evidence.** For each behavior, keep one TDD evidence row: seam authority; test file and exact test selector or explicitly named parameterized\u002Fsubtest case; observed public entry point; red command and intended plus observed failure; green command and result. Every command position replays on its own — a complete runnable command, or a stable key defined in the same evidence section and referenced with its argument. The green command is a position of its own even when it repeats the red; a back-reference such as \"same command\" or \"same suite\" is not a command or key. This skill owns that evidence.\n- **Use an authoritative verifier when it already supplies red.** If an authoritative PRD, live issue, ADR, or explicit user decision supplies an already-failing public verifier, confirm that its observed failure is the intended failure for the authorized criterion; that failure may then serve as red, without adding a duplicative test only to satisfy chronology. Keep one focused case per cycle whenever the verifier supports focus. When the verifier is indivisible and reports a finite named failure set that forms one atomic acceptance criterion, one aggregate cycle is allowed: record the verifier path and complete command, fixture or input identity, seam authority, the exact intended and observed red set, the minimal implementation, and the final green result. In this branch, the evidence row may name the verifier and input identity instead of a test file and selector, and pre-review reconciliation records `no changed tests; existing verifier evidence` and compares the existing-verifier evidence identities with their reconciliation identities in both directions.\n- **Reconcile tests to seams before review.** Before `\u002Fcode-review`, derive and retain a changed-test inventory from the scoped diff using the repository's native test structure. Keep one reconciliation row per changed test selector or explicitly named parameterized\u002Fsubtest case: test file; exact selector or case identity; observed public entry point; seam authority; TDD evidence row. File- or class-level summaries do not satisfy this gate. Compare the inventory identities with the reconciliation identities in both directions and require both differences to be empty. If a test enters through a module, helper, mutable global, side channel, or other boundary the authority did not ratify for that behavior, ratify that seam or rewrite the test at the agreed public boundary. This gate concerns the public behavior each row claims: a private-invariant test cannot substitute for that public-behavior proof. Reconcile every evidence row before `\u002Fcode-review` only after this coverage check passes.\n- **Review repairs and refactoring.** When `\u002Fcode-review` finds missing or incorrect observable behavior, `\u002Fimplement` must re-enter one new red → green slice. For each actionable finding that `\u002Fcode-review` marks `TDD re-entry required: yes`, append one evidence row keyed by review pass, axis, and finding, run the focused red, then apply only enough production repair to reach green; consume those routing fields as supplied rather than reclassifying the finding here. Never rewrite or extend an earlier row to absorb a later finding. If the same test selector is reused, the new row must name the distinct new parameterized\u002Fsubtest case and its focused red command. Before final handoff, compare the applicable finding identities in `\u002Fcode-review`'s `Findings fixed during review` ledger with the appended review-reentry row identities in both directions and require both differences to be empty. A repair that only refactors without changing behavior stays outside the red → green loop. Hand the reconciled, scoped committed change back to `\u002Fcode-review`; that skill owns finding classification and the two-axis review, `\u002Fimplement` owns the repair loop, and this skill owns TDD evidence.\n",{"name":5,"description":7},"main","9b13db1df193bd0709752040255bd64b682d3242","reports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_3e39da1f-a737-4029-bd88-f710519fe3de\u002Farms\u002Fcurrent\u002Fmethod","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence","https:\u002F\u002Fdocs.rs\u002Fskill-evidence","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck","2026-08-23 17:23:53",{"source":8,"skillName":5,"commands":31,"prompt":41,"zipAvailable":42},[32,35,38],{"tool":33,"command":34},"npx","npx skills add joeloverbeck\u002Fskill-evidence --skill tdd",{"tool":36,"command":37},"bunx","bunx skills add joeloverbeck\u002Fskill-evidence --skill tdd",{"tool":39,"command":40},"pnpm","pnpm dlx skills add joeloverbeck\u002Fskill-evidence --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_3e39da1f-a737-4029-bd88-f710519fe3de\u002Farms\u002Fcurrent\u002Fmethod\u002FSKILL.md",true,[44,50],{"path":45,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":48,"sourceHtmlUrl":49},"mocking.md","REFERENCE","参考文档",1480,"https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_3e39da1f-a737-4029-bd88-f710519fe3de\u002Farms\u002Fcurrent\u002Fmethod\u002Fmocking.md",{"path":51,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":52,"sourceHtmlUrl":53},"tests.md",3396,"https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_3e39da1f-a737-4029-bd88-f710519fe3de\u002Farms\u002Fcurrent\u002Fmethod\u002Ftests.md",[55,62,67,72,77,82],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":18},"01M7AAQDXB1QQET7VSTF1FCEET","triage","Move issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftriage\u002Freviews\u002Ffce6031a-a8f1-44b9-93cc-5c27488a51d3\u002Fcandidate\u002FSKILL.md",[],[],{"skillNo":63,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":18},"01M7AAQBCSHN0ZH9MHQZNEHCGR","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftriage\u002Freviews\u002F48b04150-c9c8-42a7-982a-324aceb6d21e\u002Fheld\u002Fember\u002FSKILL.md",[],[],{"skillNo":68,"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":69,"categories":70,"keywords":71,"publishedAt":18},"01M7AAQ8BDCGNPBVJVGQ1KWSN7","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_c25c6d82-756b-49e4-85ed-bd164820f2f2\u002Fpre-land-backup\u002FSKILL.md",[],[],{"skillNo":73,"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":74,"categories":75,"keywords":76,"publishedAt":18},"01M7AAQ6DRHY95HPCDGG7TBP93","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_c25c6d82-756b-49e4-85ed-bd164820f2f2\u002Fcandidate\u002FSKILL.md",[],[],{"skillNo":78,"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":79,"categories":80,"keywords":81,"publishedAt":18},"01M7AAQ3XN1HSP13RC35NFTKT0","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_3e39da1f-a737-4029-bd88-f710519fe3de\u002Fpre-land-backup\u002FSKILL.md",[],[],{"skillNo":83,"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":84,"categories":85,"keywords":86,"publishedAt":18},"01M7AAQ1NGVGK62GB5Z6JSNJ76","https:\u002F\u002Fgithub.com\u002Fjoeloverbeck\u002Fskill-evidence\u002Fblob\u002Fmain\u002Freports\u002Fskill-evidence\u002Ftdd\u002Freviews\u002Frev_3e39da1f-a737-4029-bd88-f710519fe3de\u002Fcandidate\u002FSKILL.md",[],[]]