TDD Test Writer

When To Use

• test-first development
• TDD / RED-GREEN-REFACTOR workflow
• writing tests that implementation agents must satisfy
• bugfixes that need regression tests before code changes

Required Rules

1. Do not modify production code while running this skill.
2. Use subagent role

   tdd_test_writer

   for RED-phase test authoring whenever available.
3. Write behavior-focused tests, not placeholders.
4. Every new/updated test must fail before handoff.
5. Failures must come from missing or incorrect production behavior, not broken tests.
6. Prefer deterministic, targeted test commands over full-suite runs when possible.
7. For bugfix tasks, add a regression test that captures the reported failure mode.

Workflow

1. Define Behavior Contract

• Convert user request into explicit acceptance criteria.
• Identify happy path, edge cases, and negative-path expectations.
• If requirements are ambiguous, record

  ASSUMPTION:

  lines in output.

2. Delegate Test Authoring To

tdd_test_writer

• Spawn a

  tdd_test_writer

  subagent with task scope, target files, and acceptance criteria.
• Require the subagent to write/update tests only (no production code changes).
• Require command output proving RED-state failure for the new tests.
• If

  tdd_test_writer

  is unavailable, continue directly and note

  FALLBACK: tdd_test_writer unavailable

  .

3. Discover Existing Test Conventions

• Detect framework and runner from the repo (for example

  vitest

  ,

  jest

  ,

  pytest

  ,

  go test

  ,

  cargo test

  ).
• Follow existing directory, naming, and fixture conventions.
• Reuse existing helpers instead of introducing duplicate test utilities.

4. Author RED-Phase Tests

• Create or update test files that encode the behavior contract.
• Keep tests small and intention-revealing (clear names and assertions).
• Include at least one negative-path assertion where applicable.
• Avoid network/time randomness; mock or fixture external systems.

5. Verify RED State

• Run the narrowest command that executes the new tests.
• Confirm they fail for the expected behavioral gap.
• If failure is caused by test syntax/setup, fix tests and rerun.

6. Produce Implementation Handoff

• subagent used (

  tdd_test_writer

  ) or explicit fallback reason
• exact test files created/updated
• exact verification command(s)
• short failure summary proving RED state
• immutable test constraint (do not edit tests unless requirement changes)
• pass criteria that define task completion

Required Output Format

TDD RED PHASE COMPLETE

## Authoring Mode
- Subagent: tdd_test_writer
- Fallback: [only if subagent unavailable]

## Test Files
- [path]

## Verification
- Command: [exact command]
- Result: FAIL (expected)
- Failure reason: [1-2 lines tied to missing behavior]

## Implementation Contract (for next agent)
1. Do not modify these tests: [paths]
2. Implement production changes only in: [paths or modules]
3. Completion gate: [exact command] passes with no test weakening.
4. Run broader safety check: [secondary command]
5. Return evidence: changed files + command output summary.

## Assumptions
- ASSUMPTION: [only if needed]

Quality Bar

• Tests fail before implementation and are reproducible locally.
• Assertions are specific enough to prevent false positives.
• Regression coverage is present for bugfix-driven tasks.
• Handoff is precise enough that another agent can execute without clarifications.