spec-tddlisted

# spec-tdd ## Overview Two-tier TDD split across the agent boundary: **the orchestrator writes the acceptance test (the spec) before any implementation exists; a subagent then implements to pass it and adds its own unit tests.** This breaks the circular reasoning that makes same-agent test+impl produce *green lies* — tests that merely mirror the implementation. Near-zero human cost because the orchestrator is AI. **Core principle:** the acceptance test is authored before any impl exists, in a different context than the implementer — so it cannot have been reverse-engineered to mirror an implementation (the structural anti-green-lie guarantee). It can still be *wrong or shallow* — a misread or under-interrogated requirement produces a bad test — but that is a different failure mode, handled by RED-first, the Phase-3 adversarial read, the grill, and the attacker. **"Must be RED first"** is the built-in green-lie detector. **Protocol:** this skill operationally enforces the spec-TDD protocol — see [PROTOCOL.md](../PROTOCOL.md) for the canonical artifacts (A1–A16) and invariants (I1–I21). ## When to Use - User says `spec-tdd <feature>` (the agreed trigger). - Implementing a feature where weak/vacuous AI-generated tests are a risk. - ONE small unit (a single bugfix-scale item, non-critical, in a session you'll clear after)? Use **`spec-tdd-lite`**, the family's in-session tier — acceptance test first, implement yourself, one fresh-context review. - MULTIPLE independent units —