---

name: write-tests description: Write failing tests from requirements. Invoke for each todo before /implement. context: fork agent: tester

/write-tests

Write failing tests that encode acceptance criteria.

Usage

Copy/write-tests
/write-tests Add logout button to header

When to Use

• After creating a todo that requires implementation
• Before running /implement
• When you have clear acceptance criteria

When NOT to Use

• Implementation already exists (tests would pass immediately)
• You're exploring or prototyping (not TDD mode)
• Just adding to existing test coverage

What It Does

1. Analyzes the current todo/requirement
2. Reads existing tests to understand patterns
3. Writes test files that verify acceptance criteria
4. Verifies tests FAIL (proves they test something real)
5. Returns test file paths for /implement

Output

The tester agent will produce:

Copy## Tests Written

### Files Created/Modified
- `tests/test_client.py`

### Tests Added
| Test | Verifies |
|------|----------|
| `test_client_reset_returns_observation` | Reset returns valid observation |
| `test_client_step_advances_state` | Step mutates state correctly |
| `test_client_handles_invalid_action` | Error handling for bad input |

### Verification
All tests FAIL as expected (no implementation yet).

### Next Step
Run `/implement` to make these tests pass.

Rules

1. Read existing tests first to understand patterns and conventions
2. Test behavior, not implementation - write from user's perspective
3. Integration tests first, then unit tests if needed
4. Each test verifies ONE thing clearly
5. Run tests to verify they fail before returning

Anti-patterns (NEVER do these)

• Writing tests that pass without implementation
• Testing implementation details instead of behavior
• Writing overly complex test setups
• Adding implementation code (that's /implement's job)
• Writing tests that duplicate existing coverage

Completion Criteria

Before returning, verify:

1. Tests compile/run successfully (pytest can collect them)
2. Tests FAIL (no implementation yet)
3. Test names clearly describe what they verify
4. Tests follow existing project patterns (see tests/ for examples)