No failing tests exist (run /write-tests first)
You want to add features not covered by tests
You want to refactor (use /simplify instead)

What It Does

Finds the failing tests from /write-tests
Reads tests to understand requirements
Writes the minimum code to make tests pass
Runs tests after each change
Stops when ALL tests pass

Output

The implementer agent will produce:

## Implementation Complete

### Tests Passed
- `test_client_reset_returns_observation` ✓
- `test_client_step_advances_state` ✓
- `test_client_handles_invalid_action` ✓

### Changes Made
| File | Change |
|------|--------|
| `src/openenv/core/client.py` | Added `reset()` method |
| `src/openenv/core/client.py` | Added `step()` method |
| `src/openenv/core/client.py` | Added input validation |

### Verification

PYTHONPATH=src:envs uv run pytest tests/test_client.py -v All 3 tests passed


### Next Steps
- Mark todo as complete
- Consider `/simplify` if change was large
- Move to next pending todo

Rules

Read the failing tests first to understand exactly what's needed
Write the MINIMUM code needed to pass tests
Run tests after each change to verify progress
Do NOT add extra features not covered by tests
Do NOT refactor existing code (that's /simplify's job)
Stop when all tests pass

Anti-patterns (NEVER do these)

Adding features not covered by tests
Refactoring existing code
Writing additional tests (that's /write-tests's job)
Over-engineering solutions
Adding comments or documentation beyond what's necessary
"Improving" code that already works

Completion Criteria

Before returning, verify:

ALL tests pass
No new test failures introduced
Implementation is minimal and focused

Philosophy

The implementer is a "code machine" - it takes test specifications and produces the minimal code to satisfy them. This keeps implementations focused and prevents scope creep.

Think of it as TDD's second phase: Red → Green → Refactor. You are "Green" - make tests pass, nothing more.

implement

/implement

Usage

When to Use

When NOT to Use