spec-tdd-litelisted

# spec-tdd-lite **REQUIRED BACKGROUND:** Understand the `spec-tdd` family first — `spec-tdd` in particular (acceptance-test-first, must-be-RED, the green lie). This skill is the family's **in-session tier**: the same discipline with zero delegation, plus ONE fresh-context review dispatch. ## Overview The acceptance test (the spec) is written **before any impl exists**, then implemented **in the same session**, then — after GREEN — **one subagent that never saw the implementation reviews the test**: could it stay green under a subtly-wrong impl, and does it assert the requirement? **Core principle:** written-first blocks the test mirroring the impl; the fresh-context review blocks the shallow assertion. Those are the two green-lie vectors — covered at a fraction of full `spec-tdd`'s cost. **What this gives up vs `spec-tdd` (honest):** no fresh implementer re-reading your spec (a misread requirement can sail green — the review's test-vs-requirement question is the mitigation), no SPEC-INTEGRITY hash (test immutability here is the solo re-RED discipline, not structure), and the inner loop stays in your main context — pollution is the price; budget a clear/compact after the session's work. ## The gap this closes Observed baseline: a diligent plain-TDD agent, on a small coupon feature, shipped a 6/6-green suite in which (a) "written first, failed first" was an **unverifiable self-report**; (b) an ambiguous requirement line ("integer 0–100; outside that range → throw") was s