Code Simplifier

Overview

Simplify touched code without changing behavior. Prefer explicit, readable code over clever or overly compact rewrites, and keep scope limited to the files or sections the user just changed unless they request broader cleanup.

When to Use

• The user asks to "simplify", "clean up", "tidy", or "refactor without changing behavior"
• Recently modified code works, but has duplication, deep nesting, noisy comments, or inconsistent naming
• A feature is complete and you want a maintainability pass before formal review
• You want one focused simplification pass, not a multi-agent review workflow

Do not use this skill for:

• Behavior changes, feature work, or bug fixes that alter requirements
• Large architectural redesigns across untouched modules
• Spec alignment review, security review, or performance review
• Three-reviewer cleanup workflows; use simplify for that

Workflow

1. Define the Scope

• Use user-specified files or ranges if provided
• Otherwise inspect recent changes with git diff, git diff --name-only, or git status
• Default to touched code only; do not expand into unrelated cleanup

2. Read Local Standards

• Check project instructions first such as AGENTS.md, local skill rules, and repo conventions
• Follow existing naming, formatting, and structure in the touched files
• If local conventions conflict with generic cleanup preferences, local conventions win

3. Simplify Without Changing Semantics

• Reduce unnecessary nesting
• Remove duplication that is truly local and obvious
• Rename variables or helpers only when clarity improves and the rename is safe
• Prefer straightforward control flow over dense one-liners
• Avoid nested ternaries; use if/else or switch for multi-branch logic
• Remove comments that only restate the code; keep comments that explain intent or constraints
• Preserve helpful abstractions; do not flatten structure just to reduce line count

4. Guardrails

• Do not add features, options, or speculative generalization
• Do not broaden API surface or change data contracts
• Do not rewrite untouched modules for style consistency alone
• Do not claim "no behavior change" without verification

5. Verify

• Run the narrowest meaningful verification for the changed area
• Prefer targeted tests first, then broader lint/build checks if appropriate
• If no automated verification exists, state that explicitly and mention residual risk

Quick Reference

Common Mistakes

• Turning simplification into redesign
• Extracting abstractions too early
• Renaming broadly across unrelated files
• Optimizing for fewer lines instead of easier maintenance
• Skipping verification because the change "looks mechanical"

Upstream Reference

This Codex skill is adapted from Anthropic's code-simplifier plugin agent. See references/upstream-agent.md for the source location and adaptation notes.