write-tests

---
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

```
/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:

```markdown
## 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)