{"id":19274,"plugin_id":"plugins_6a952d7c729c819196646fda7ec9ad94","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:15:26.541Z","digest":"1855609b276c0a4552fd1beaa4d54f9340819004829dc79d865b9f89e9e792ef","against":null,"payload":{"description":"Apply risk-based test-driven development to bugs, domain logic, state transitions, parsers, contracts, migrations, and behavior where a failing test sharpens the design.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":365},{"relative_path":"assets/icon-400.png","size_in_bytes":1307},{"relative_path":"assets/icon.svg","size_in_bytes":1913}],"name":"tdd","skill_md_contents":"---\nname: tdd\ndescription: \"Apply risk-based test-driven development to bugs, domain logic, state transitions, parsers, contracts, migrations, and behavior where a failing test sharpens the design.\"\n---\n\n# TDD\n\nUse tests as design and evidence. Preserve strict red-green discipline where it pays off, and use lighter verification where the ceremony would add little signal.\n\n## Choose the testing mode\n\n### Strict red-green\n\nPrefer for:\n\n- Bug fixes with a reproducible failure\n- Domain rules and calculations\n- State machines and mutations\n- Parsers, serializers, validators, and data transforms\n- API contracts and compatibility behavior\n- Migrations\n- Concurrency or race-condition fixes\n- Security-sensitive behavior\n\nCycle:\n\n1. Write the smallest behavior-focused test.\n2. Execute it once and verify that the failure matches the intended behavioral gap.\n3. Implement the minimum coherent change.\n4. Run the focused test and confirm it passes.\n5. Refactor while keeping it green.\n6. Run nearby tests.\n\n### Characterization-first\n\nUse for legacy code whose behavior is poorly documented.\n\n1. Add tests that capture relevant current behavior.\n2. Add a failing test for the behavior that must change.\n3. Implement the change.\n4. Keep unrelated characterized behavior stable.\n\n### Test-alongside\n\nReasonable for:\n\n- Pure styling and visual polish\n- Copy changes\n- Simple configuration or wiring\n- Generated files\n- Small adapters already covered by higher-level tests\n- Prototypes or short-lived spikes\n\nUse the most meaningful existing checks. Add automated tests when there is a real regression surface, not to satisfy a quota.\n\n## Existing implementation\n\nDo not delete valid work merely because implementation preceded the test.\n\nWhen code already exists:\n\n- Reproduce the bug against the current code.\n- Add a test that fails on the current behavior when possible.\n- If the fix has already been applied, temporarily revert or mutate the narrow change only when safe and efficient to prove the test catches it.\n- Otherwise document why red-state proof was impractical and use strong behavior verification.\n\n## Test quality\n\nPrefer tests that:\n\n- Assert externally meaningful behavior\n- Fail for one understandable reason\n- Are deterministic\n- Use real code through stable boundaries\n- Survive internal refactoring\n- Cover important edge and error paths\n- For optional host capabilities, distinguish absence (no doomed action plus useful degradation), rejection, cancellation, policy denial, and success when those are separate observable results\n\nAvoid:\n\n- One test for every trivial function\n- Snapshot tests that hide semantic changes\n- Mocking the unit under test\n- Asserting private implementation details\n- Huge fixtures when a focused case works\n- Adding sleeps for asynchronous behavior when a condition can be awaited\n\n## Mocks and fakes\n\nUse real collaborators when cheap and deterministic. Mock or fake:\n\n- Network boundaries\n- Time\n- Randomness\n- External services\n- Slow or destructive infrastructure\n\nKeep mocks at stable interfaces. If every internal call must be mocked, reconsider coupling.\n\n## Regression proof\n\nFor a bug fix, the ideal evidence is:\n\n- Test fails before fix for the expected reason\n- Test passes after fix\n- Nearby suite remains green\n\nDo not perform risky repository surgery merely to reenact red-green after the fact. Evidence should increase confidence, not damage the workspace.\n\n## Completion checklist\n\nBefore claiming test-backed behavior:\n\n- The test targets the requested behavior.\n- Failure and success reasons are understood.\n- Important boundary cases are represented.\n- Focused tests pass after the final relevant change.\n- Broader checks were run when risk justifies them.\n- Any untested area is stated honestly.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}