spectre-tdd

name	spectre-tdd
description	Load this skill when executing TDD (Test-Driven Development) methodology. Use when implementing features via strict RED-GREEN-REFACTOR cycles, or when a prompt instructs execution via TDD.

TDD: Test-Driven Development Methodology

Execute tasks using strict TDD (RED → GREEN → REFACTOR). Outcome: Tasks completed with Happy/Failure tests passing, minimal code shipped.

Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Wrote code before the test? Delete it. Start over. Don't keep it as "reference." Don't "adapt" it. Delete means delete. Implement fresh from tests.

Rules

• 2 tests per Test Opportunity (TO): 1 Happy path, 1 Failure path — then stop
• Scoped execution: Never run repo-wide tests; use --testPathPattern, --findRelatedTests, or per-file lint
• YAGNI: No abstractions unless test forces it or ≥2 call sites exist
• Anti-flake: Use fake timers, stubs, seeded RNG

---

Step 1 - Generate TDD TODO List

• Action — ParseTaskList: Extract tasks from ARGUMENTS or thread context
  • If no clear tasks → stop and ask for guidance
• Action — IdentifyTestOpportunities: Derive TOs (smallest behavior unit: function, route, bug fix, acceptance criterion)
• Action — TransformToTDD: Convert each TO to cycle using TodoWrite:
  • RED: Happy — {test} → RED: Failure — {test} → GREEN: Minimal impl → REFACTOR: Tidy → COMMIT
• Action — VerifyScope: Confirm TODO contains ONLY assigned tasks

Step 2 - RED Phase: Write Failing Tests

• Action — WriteHappyTest: Write first failing test (happy path)
  • Execute only this test/file, not entire suite
• Action — WriteFailureTest: Write second failing test (primary failure mode)
• Action — VerifyRed: MANDATORY — Confirm each test:
  • Fails (not errors)
  • Fails for expected reason (feature missing, not typo)
  • If passes → you're testing existing behavior; fix test

Step 3 - GREEN Phase: Minimal Implementation

• Action — ImplementMinimal: Write least code to pass tests
  • No extra branches, params, or dependencies unless test forces them
• Action — VerifyGreen: MANDATORY — Run tests (narrowest scope)
  • If fail → fix code, not test
  • Remove any speculative code not forced by tests

Step 4 - REFACTOR Phase: Clean Code

• Action — RefactorSafely: Improve only if duplication ≥3 OR readability materially improves
  • Keep tests green; If tests fail → revert
• Action — HandleLintFailures: Apply in order until clear:
  1. Guard clauses, split compound expressions
  2. Extract tiny private helpers (same file)
  3. Hoist literals to file constants
  4. Split into orchestrator + helpers
  5. Only if still failing: same-directory helper module

Step 5 - Loop or Complete

• If more TOs → return to Step 2
• Else → proceed to Step 6

Step 6 - Commit & Report

• Action — CommitCode: Conventional format (feat({task}): description)
• Action — GenerateReport:
  • Summary: Tasks completed, test status (✅ Happy ✅ Failure), files modified
  • Artifacts: Test helpers, mocks, fixtures created
  • API Surface: New/modified exports with signatures
  • Patterns: Code/testing patterns to follow
  • Deferred: Coverage gaps for follow-up

---

Red Flags — STOP and Restart

If any of these occur, delete code and start over with TDD:

Red Flag	Why It's Wrong
Code written before test	Violates Iron Law
Test passes immediately	Testing existing behavior, not new
Can't explain why test failed	Don't understand what you're testing
"Just this once" thinking	Rationalization — TDD has no exceptions
Keeping code "as reference"	You'll adapt it; that's tests-after

When Stuck

Problem	Solution
Don't know how to test	Write wished-for API first, then assert on it
Test too complicated	Design too complicated — simplify interface
Must mock everything	Code too coupled — use dependency injection
Test setup huge	Extract helpers; still complex? Simplify design

Pre-Completion Checklist

Before marking complete, verify:

• Every new function has a test
• Watched each test fail before implementing
• Each failure was for expected reason
• Wrote minimal code to pass
• All tests pass, output clean
• Mocks used only when unavoidable