simplify
$
npx mdskill add huggingface/OpenEnv/simplifyRefactor and clean up code after tests pass.
SKILL.md
.github/skills/simplifyView on GitHub ↗
---
name: simplify
description: Refactor code after tests pass. The "Refactor" phase of Red-Green-Refactor.
context: fork
agent: code-simplifier
---
# /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
1. Runs tests to ensure they pass (baseline)
2. Identifies opportunities for simplification
3. Refactors while keeping tests green
4. 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
1. All tests still pass
2. Code is cleaner/simpler than before
3. No new functionality was added
4. 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
```
More from huggingface/OpenEnv
- alignment-reviewReview code changes for bugs and alignment with OpenEnv principles and RFCs. Use when reviewing PRs, checking code before commit, or when asked to review changes. Implements two-tier review model.
- deploy-hfDeploy an OpenEnv environment to Hugging Face Spaces. Use when asked to deploy, push to Hugging Face, or update a space.
- generate-openenv-envGenerate OpenEnv environments from a concrete use case (for example, "generate an env for the library textarena"). Use when asked to design or implement a new environment under envs/ by researching a target library/API, selecting matching OpenEnv examples, asking key implementation questions, and building models/client/server/openenv.yaml. Do not use for model training or evaluation tasks.
- hf-space-recoveryDiagnose and recover failing or stuck Hugging Face Space deployments for OpenEnv environments. Use when deploying envs from `envs/` to the Hub (`openenv` namespace with version suffixes), when Spaces are in `BUILDING`/`APP_STARTING`/`RUNTIME_ERROR`, or when release collections need to be reconciled after targeted redeploys.
- implementMake tests pass. Invoke after /write-tests produces failing tests.
- openenv-cliOpenEnv CLI (`openenv`) for scaffolding, validating, building, and pushing OpenEnv environments.
- pre-submit-prValidate changes before submitting a pull request. Run comprehensive checks including lint, tests, alignment review, and RFC analysis. Use before creating a PR, when asked if code is ready for review, or before pushing for PR.
- releaseRelease workflow for deploying OpenEnv environments to Hugging Face Spaces and keeping canonical references in sync.
- rfc-checkDetermine if proposed changes require an RFC. Use when planning significant changes, before starting major work, or when asked whether an RFC is needed.
- sprintWork on a batch of GitHub issues in parallel using Agent Teams. Creates one worktree per issue with TDD enforcement, coordinates via a lead agent, then produces stacked PRs.