| name | caspar-tdd |
| description | Execute implementation via strict red/green/refactor — derive test opportunities, write happy + failure tests, confirm RED failures before any production code, ship minimal GREEN code, then report test evidence. Trigger when a task or prompt requires TDD, failing-test-first, or RED-GREEN-REFACTOR execution (e.g. invoked by fix/execute). Do NOT trigger for test auditing, risk classification, or test planning without implementation — use caspar-test for that. |
tdd
Implement assigned behavior through strict RED → GREEN → REFACTOR. Outcome: tasks done with happy + failure tests passing and only test-forced production code shipped.
Inputs
$ARGUMENTS or thread context — the assigned implementation task(s). If no clear task, stop and ask.- The task's acceptance criteria / artifact, if one exists.
Working Set (late-bound — read at run-time, never inline)
- Target behavior, acceptance criteria, and the smallest affected code/test files.
- Narrow test/lint commands for those files only (
--testPathPattern, --findRelatedTests, per-file lint, or equivalent).
- Existing test helpers, fixtures, stubs, fake timers, seeded-RNG patterns.
Outputs + DONE
- A todo list with one cycle per Test Opportunity:
RED happy → RED failure → GREEN minimal impl → REFACTOR → COMMIT.
- The implementation diff, focused tests, and (optional) conventional commit
feat({task}): description.
- A completion report: Summary (tasks done, ✅ happy / ✅ failure test status, files modified); Artifacts (helpers/mocks/fixtures); API Surface (new/modified exports + signatures); Patterns; Deferred coverage gaps.
DONE when: every Test Opportunity has exactly one happy-path and one primary-failure test (unless the behavior genuinely supports only one); each new test was observed failing for the expected reason before its implementation; minimal production code makes the focused tests pass; refactors left the tests green; every new function has a test; all focused tests + relevant lint pass cleanly.
Method / guardrails
- Iron Law — YOU MUST confirm RED before GREEN. No production code before a failing test. If code was written first, delete it and restart from the tests — do not keep it as reference, do not adapt it.
- A Test Opportunity is the smallest behavior unit: a function, route, bug fix, or acceptance criterion.
- Per Test Opportunity: write the happy test, then the primary-failure test; run the narrowest command; confirm both fail (not error) for the missing behavior, not a typo/setup bug. A test that passes immediately is testing existing behavior — fix it or pick uncovered behavior.
- GREEN = the least code to pass the focused tests: no extra branches, params, dependencies, or abstractions unless a test forces them or ≥2 call sites exist (YAGNI).
- Refactor only while green, and only for duplication ≥3 or a material readability gain; if a refactor breaks tests, revert it.
- Resolve lint pressure in order: guard clauses / split compounds → tiny same-file helpers → file constants → orchestrator + helpers → same-directory helper module only if still failing.
- Keep execution scoped — never run repo-wide tests when a focused command exists.
- Prefer the repo's existing anti-flake patterns: fake timers, stubs, seeded RNG, deterministic fixtures.
Handoff
Return the completion report inline with the exact commands run and pass/fail evidence — no scratch files. Then render the inline Next Steps line: caspar-clean to tidy, or caspar-test for broader risk-based verification.
Escalate-If
- The assigned task or its acceptance criteria are unclear → stop and ask.
- You cannot make a meaningful RED test fail for the expected reason.
- The focused test command cannot be isolated to the changed files.
- Test setup dwarfs the behavior under test → the design is too coupled; simplify the interface (or ask) before continuing.
