tdd-loop

Spec 006 promoted this skill from a dangling auto-install reference to an active skill. The deterministic runner detection + subprocess invocation live in tdd.py; this SKILL.md drives the judgment layer.

What this skill does

Codifies the red-green-refactor loop that the implementer subagent (agents/implementer.md) already encodes as "non-negotiable TDD discipline." The skill:

• Detects the project's test runner from filesystem signals (one of pytest, vitest, jest, or Node's built-in node --test).
• Invokes the runner as a subprocess against a target, a focused --test-path, or a single --test selector.
• Streams the runner's stdout/stderr through to the caller — you see real output, not a swallowed summary.
• Normalizes the runner's native exit code so callers can branch deterministically:
  • 0 — all green
  • 1 — at least one red test (runner started but reported failure)
  • 2 — could not detect a runner, OR the runner binary is missing

The red-green-refactor loop

1. Red. Write a failing test for one acceptance criterion (or one well-bounded behaviour). Run tdd.py run <target> and confirm the new test is the only new failure — exit 1.
2. Green. Write the minimum implementation that makes the test pass. Run tdd.py run <target> again; expect exit 0.
3. Refactor. Clean up only after green. Re-run after each meaningful refactor; exit 0 must hold.

Stay in this loop one AC at a time. Do not write three tests and then three implementations — the loop's value is the tight feedback cycle.

When a test you did NOT just write goes red

The Green step above is about the new failing test you wrote for this AC — making it pass is the work. A pre-existing test going red is the opposite signal: it is a guard reporting that your change touched something load-bearing. The reflex to "make it green" is wrong here, and an agent is very good at satisfying it — deleting the assertion, loosening the expectation, or marking the test skipped all turn the light green while removing the protection.