# Simplify

> Review and refactor only the current Git working-tree changes for reuse, code quality, and efficiency, then apply safe behavior-preserving improvements. Use when the user invokes /simplify or $simplify, or explicitly asks to simplify the code changed in the current diff.

- Skill: `steventswu/simplify` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add steventswu/simplify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/steventswu/simplify/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: steventswu (https://skillmd.com/u/steventswu)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/steventswu/simplify

---


# Simplify

Improve the current change set without expanding into a repository-wide cleanup. Review first, then edit the code to address findings that materially improve clarity, maintainability, reuse, or efficiency while preserving behavior.

## Establish the change scope

1. Read the applicable `AGENTS.md` files and repository guidance.
2. Inspect `git status --short`, the unstaged diff, the staged diff, and relevant untracked files.
3. Build the allowed file list from files that are currently modified, staged, or untracked. Do not edit files outside this list unless the user explicitly broadens the scope.
4. Treat existing user changes as intentional. Do not revert them, discard them, overwrite unrelated work, or rewrite an entire file merely to simplify a small changed region.
5. If there are no current changes, stop and report that there is no diff to simplify.

Focus analysis on changed hunks and the code paths they directly affect. Read nearby code and existing utilities as needed to understand conventions and reuse opportunities, but do not turn that inspection into unrelated edits.

## Run three reviews in parallel

When multi-agent collaboration is available, launch exactly three independent review agents concurrently. Give every reviewer the allowed file list, current diff, applicable repository instructions, and a read-only assignment. Tell them not to edit files. Use these lanes:

- **Code Reuse Review:** Find newly introduced duplication, reimplemented helpers, and opportunities to use existing utilities or shared abstractions. Reject reuse that increases coupling or obscures simple logic.
- **Code Quality Review:** Find avoidable complexity, hacky patterns, duplicated or derived state, leaky abstractions, unclear naming, excessive nesting, brittle error handling, and comments that merely restate the code.
- **Efficiency Review:** Find unnecessary work, repeated I/O or computation, accidental sequential operations that are safely independent, N+1 behavior, wasteful allocations, and regressions on hot paths. Do not propose speculative micro-optimizations.

Ask each reviewer to return only concrete, behavior-preserving findings, with file and line references, rationale, and a minimal proposed fix. Reviewers may inspect the wider repository for context but must keep findings tied to the current change set.

If multi-agent collaboration is unavailable, perform the same three lanes yourself and state that they were run sequentially.

## Reconcile and apply

Evaluate all findings against the actual code. Ignore duplicates, subjective churn, speculative improvements, and suggestions that conflict with repository conventions or change behavior. Prefer clear, explicit code over dense expressions, clever one-liners, or nested ternaries.

Apply the accepted fixes directly, restricted to the allowed file list. Preserve public APIs, outputs, side effects, error semantics, ordering, and compatibility unless the user explicitly requested a behavior change. Do not add abstractions whose cost exceeds their reuse value.

After editing, inspect the resulting diff to ensure every edit serves the simplification task and no unrelated content changed.

## Verify

Run the smallest relevant formatting, lint, type-check, and test commands supported by the repository, expanding verification only when risk warrants it. Do not claim behavior is preserved solely from inspection when executable checks are available.

Finish with a concise summary of:

- the meaningful improvements applied;
- validation performed and its result;
- any finding deliberately not applied and why;
- any verification limitation or pre-existing failure.

Do not commit, push, or open a pull request unless the user separately asks.