Simplify

/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