← ClaudeAtlas

tddlisted

Write the failing test before the implementation, for a single piece of code — red, green, refactor. A finer grain than the ledger's task-level verify.command (subagent-driven-development); use this INSIDE an implementer's work on one task, not as a replacement for the ledger.
bharat3645/The-Ideal-Harness · ★ 5 · AI & Automation · score 71
Install: claude install-skill bharat3645/The-Ideal-Harness
# TDD (red, green, refactor) `subagent-driven-development`'s ledger verifies a whole TASK is done via `verify.command`. This skill is the finer-grained discipline for the code written INSIDE one task: prove the test fails for the right reason before making it pass, one small cycle at a time. The two compose — a task's `verify.command` is often literally "run the test suite this skill was used to write." ## Process 1. **Write one test for the next smallest behavior**, not the whole feature. Name it for the behavior, not the implementation ("rejects a negative amount", not "test3"). 2. **Run it and confirm it fails for the stated reason** — a test that passes before the code exists, or fails with an unrelated error, proves nothing. Read the actual failure output. 3. **Write the minimum code to pass it.** Resist writing more than the current test demands; the next test will demand the next piece. 4. **Run the full local suite**, not just the new test — a green new test next to a broken old one is not progress. 5. **Refactor with the tests green**, if the code asks for it. Never refactor and add behavior in the same step — that's two changes wearing one commit. 6. Repeat from 1. ## Boundary This is a per-change discipline, not a project methodology mandate — some code (glue, config, generated bindings) isn't worth testing this granularly, and this skill doesn't override that judgment. It also isn't a substitute for the ledger's task-level `verify.command`: a t