{"id":17563,"plugin_id":"plugins_6a78e83987748191afc0c56e12172fce","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:15.852Z","digest":"7ab4137b4079b48dc69fa49a8e0a45e633c49e4b63db6ba6d33ce8e3f40bdbb5","against":null,"payload":{"description":"Implement features and bug fixes test-first using red-green-refactor cycles. Use when writing new functionality, adding regression tests, fixing bugs with test coverage, or designing behavior through test assertions — even if the user says \"write tests for this\". Do NOT use for throwaway exploratory prototypes.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":87},{"relative_path":"mocking.md","size_in_bytes":1481},{"relative_path":"tests.md","size_in_bytes":2214}],"name":"tdd","skill_md_contents":"---\nname: tdd\ndescription: \"Implement features and bug fixes test-first using red-green-refactor cycles. Use when writing new functionality, adding regression tests, fixing bugs with test coverage, or designing behavior through test assertions — even if the user says \\\"write tests for this\\\". Do NOT use for throwaway exploratory prototypes.\"\n---\n\n# Test-Driven Development (TDD)\n\nImplement robust, maintainable functionality through disciplined red → green → verify cycles. Verify behavior through public seams rather than private implementation details.\n\n## Core Principle\n\n> **Write the failing test first, witness it fail for the right reason, and write only the minimal code needed to make it green.**\n\n---\n\n## Core Invariants\n\n1. **Strict Red-First Execution**: Never write production implementation code before seeing an automated test fail against a pre-agreed seam.\n2. **Behavioral Testing Over Implementation Inspection**: Tests must assert observable input/output behavior and public contracts, never private variables or internal call chains.\n3. **Independent Expected Values**: Assertions must compare against independent ground truth (fixtures, domain specs, known literals), never recomputed mirror logic.\n4. **Vertical Tracer Slicing**: Deliver one vertical slice at a time (one test → minimal code → green) rather than batching horizontal test suites upfront.\n5. **Deterministic & Isolated Fixtures**: Tests must execute in milliseconds without cross-test state leakage, unseeded random seeds, or unpinned clocks.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Agree Public Seam ] ──► [ Red: Write Failing Test ] ──► [ Green: Minimal Code ] ──► [ Refactor & Verify ]\n```\n\n| Component | Responsibility | Reference |\n|---|---|---|\n| **Public Seams** | Identify module boundaries and observable behaviors | `codebase-design` |\n| **Test Examples** | Concrete patterns for unit and integration assertions | `tests.md` |\n| **Mocking Guidelines** | Safe boundary isolation rules without over-mocking | `mocking.md` |\n| **Review & Refactor** | Clean code review after reaching green | `code-review` |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Identify & Confirm the Public Seam\n- **Action**: State the public interface and observable contract you intend to test, and confirm alignment with domain conventions.\n- **Key Point**: Anchor assertions at public boundaries; do not reach into internal private state.\n- **Why**: Testing through private internals creates brittle tests that break during harmless refactoring.\n\n### Step 2: Write the Failing Test (RED)\n- **Action**: Author a single focused test specifying the expected behavior and run the test runner to observe failure.\n- **Key Point**: Verify the test fails specifically because the new behavior is absent, not due to syntax or setup errors.\n- **Inline Checklist**:\n  - [ ] Test names the exact business capability (e.g. `returns_discounted_total_for_premium_member`)\n  - [ ] Test fails with expected assertion error\n  - [ ] Expected values derived from independent domain constants\n- **Why**: A test that doesn't fail properly cannot be trusted to protect against regressions.\n\n### Step 3: Implement Minimal Code (GREEN)\n- **Action**: Write the simplest, most direct code that makes the failing test pass.\n- **Key Point**: Do not anticipate speculative requirements or write unexercised branches.\n- **Why**: Minimal code keeps the change set tight and prevents unverified dead logic.\n\n### Step 4: Verify Suite & Cycle\n- **Action**: Run the full test suite to guarantee zero regressions.\n- **Key Point**: All tests must be green before proceeding to the next vertical tracer slice.\n- **Why**: Catching regressions immediately keeps debugging costs near zero.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"I'll write the implementation first, then add tests.\"* | **Forbidden: test must be written and observed failing first.** | Tests written after code tend to mirror implementation bias and miss edge-case failures. |\n| *\"I can mock this internal helper to test the private method.\"* | **Test only through public seams.** | Mocks on private internals cement architectural rigidity and hide real integration bugs. |\n| *\"I will write all 15 test cases before writing any code.\"* | **Vertical tracer slicing: one test at a time.** | Bulk tests lock in premature interface assumptions before real implementation learnings. |\n| *\"The test passed on the first run without changes.\"* | **Investigate immediately: tautological or wrong test.** | A test that passes without implementation changes is asserting something already true. |\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}