tdd

name	tdd
description	Trigger only when the user explicitly requests test-driven implementation or when an assigned task requires adding behavior by first writing a failing test, then minimal code, then refactoring without behavior change.
requires	[]

tdd — Strict RED/GREEN/REFACTOR Skill

1. Trigger Boundary

Use this skill only when the task requires a Test-Driven Development loop:

• User explicitly asks for TDD.
• A plan task requires adding behavior through a failing test first.
• An executer needs a disciplined RED/GREEN/REFACTOR cycle for a scoped behavior.

Do not use this skill for pure verification, code review, debugging without a target behavior, or implementation where tests are intentionally out of scope.

2. Non-Negotiable Constraints

• RED before production code. Do not edit implementation code until a failing test for the target behavior has been written and run.
• Valid RED only. The failing test must fail because the target behavior is missing or wrong, not because of syntax errors, bad imports, broken fixtures, or unrelated environment failure.
• Minimal GREEN. Implement the smallest change that makes the RED test pass.
• Safe REFACTOR. Refactor only after tests pass, and preserve behavior.
• Test after every phase. Run targeted tests after RED, GREEN, and REFACTOR.

3. TDD State Machine

State A — Scope Behavior

Define:

• Target behavior.
• Target implementation file.
• Target test file.
• Existing related tests.
• Done criteria.

State B — RED

1. Write or update the smallest failing test that captures the target behavior.
2. Run the targeted test command.
3. Confirm the failure reason matches the intended missing behavior.
4. Stop if RED fails for an invalid reason.

State C — GREEN

1. Modify implementation code minimally.
2. Run the targeted test command.
3. Continue only when the target test passes.

State D — REFACTOR

1. Clean up duplication, naming, or local structure only when useful.
2. Do not change behavior.
3. Re-run targeted tests.
4. Run broader relevant checks if the change affects shared behavior.

4. Negative Prompts

• Never write implementation before confirming RED.
• Never accept a failing test caused by syntax/import/setup errors as valid RED.
• Never introduce broad refactors during GREEN.
• Never enter REFACTOR while tests are failing.
• Never declare completion without a final passing test run.
• Never expand the target behavior beyond the assigned task.

5. Final Output Format

status: red | green | refactored | blocked
behavior: string
filesModified: string[]
red:
  testWritten: boolean
  command: string
  failedForExpectedReason: boolean
  evidence: string
green:
  implementationChanged: boolean
  command: string
  passed: boolean
  evidence: string
refactor:
  performed: boolean
  command: string
  passed: boolean
  summary: string
blockedReason: string | null
nextAction: none | fix-red | implement-green | refactor | ask-user