/simplify

Refactor and clean up code after tests pass.

Usage

/simplify /simplify src/openenv/core/client.py

When to Use

• After /implement makes tests pass

• When code is correct but could be cleaner

• Before creating a PR (optional polish step)

When NOT to Use

• Tests are failing (fix tests first)

• You want to add new functionality (use /write-tests first)

• Code is already clean and simple

What It Does

• Runs tests to ensure they pass (baseline)

• Identifies opportunities for simplification

• Refactors while keeping tests green

• Runs tests after each change to verify nothing broke

Philosophy

This is TDD's third phase: Red → Green → Refactor.

The goal is NOT to add features or change behavior. The goal is to make the code:

• Easier to read

• Easier to maintain

• More consistent with project patterns

• Less duplicated

Guidelines

Good Simplifications

• Extract helper functions to reduce duplication

• Rename variables for clarity

• Remove dead code

• Simplify complex conditionals

• Use more Pythonic idioms

NOT Simplifications (Avoid)

• Adding new features

• Changing public APIs

• "Improving" code that works and is readable

• Adding abstractions for hypothetical future needs

Completion Criteria

• All tests still pass

• Code is cleaner/simpler than before

• No new functionality was added

• Changes follow project patterns (see PATTERNS.md)

Integration with TDD Workflow

/write-tests → create failing tests (Red) ↓ /implement → make tests pass (Green) ↓ /simplify → clean up code (Refactor) ↓ /pre-submit-pr → validate before PR