/simplify

name: simplify
description: Review changed code for reuse opportunities, quality issues, and inefficiencies using three parallel review agents, then fix any issues found. Triggers when the user says "simplify", "clean up the code", "review the changes", or after run-plan execution when code quality verification is needed.

Simplify

Reviews all changed files through three parallel agents — reuse, quality, and efficiency — then fixes any issues found.

Core Principle

Changed code is the only review target. Each review dimension runs independently, sees the full diff, and reports findings without knowledge of the other agents' results. The main agent aggregates and applies fixes.

Hard Gates

1. **Identify changes before reviewing.** Always run `git diff` (or `git diff HEAD` if there are staged changes) first. Never review without knowing what changed. 2. **All three agents must run in parallel.** Sequential execution of the three review agents is prohibited. Dispatch all three concurrently in a single message. 3. **Each agent receives the full diff.** Do not split or filter the diff per agent. Every agent sees every change. 4. **Fix issues directly.** This skill produces code changes, not just a report. If a finding is actionable, fix it. 5. **Skip false positives silently.** If a finding is not worth addressing, move on. Do not argue with the finding or explain why it was skipped. 6. **Do not expand scope beyond the diff.** Review only the changed code. Do not refactor untouched code, even if it has the same issues.

When To Use

• After any implementation work when code quality verification is needed
• When the user says "simplify", "clean up", "review the changes", or "check the code"
• After run-plan execution, before review-work, as an intermediate quality pass
• When the user suspects duplicated logic, inefficiencies, or hacky patterns in recent changes

When NOT To Use

• When there are no changes (no diff output)
• When the user wants a full codebase audit (this skill reviews only the diff)
• When the user wants only formatting or linting fixes
• When the goal is plan verification (use `review-work` instead)

Process

Phase 1: Identify Changes

1. Run `git diff` to see unstaged changes 2. If no output, run `git diff HEAD` to check staged changes 3. If still no output, check for recently modified files that the user mentioned or that were edited earlier in this conversation 4. If no changes can be identified, notify the user and stop

Capture the full diff output — this is the input for all three agents.

Phase 2: Launch Three Review Agents in Parallel

Dispatch all three agents concurrently via the Agent tool in a single message. Each agent receives the full diff and its review prompt below.

**What to provide to each agent:**

• The full diff output from Phase 1
• The agent's review prompt (copied verbatim from the corresponding section below)

**What NOT to provide:**

• Other agents' findings (agents run independently)
• Instructions to fix issues (agents only report findings)

Agent 1: Code Reuse Review

Provide this prompt to the agent:

> You are reviewing a code diff for reuse opportunities. Your job is to find new code that duplicates functionality already in the codebase. > > For each change in the diff: > > 1. **Search for existing utilities and helpers** that could replace newly written code. Search utility directories (`utils/`, `helpers/`, `lib/`, `common/`, `shared/`), files adjacent to the changed ones, and files imported by the changed files. > 2. **Flag any new function that duplicates existing functionality.** Report the new function, the existing function, and where the existing one lives. > 3. **Flag inline logic that could use an existing utility.** Common candidates: hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards, manual array/object transformations, date/time formatting done inline. > 4. **Flag reimplemented standard library features.** Check if the change reimplements something available in the language's standard library or in already-installed dependencies. > > For each finding, report: > - **Reuse opportunity:** [brief description] > - New code: [file:line] — [what was written] > - Existing: [file:line] — [what already exists] > - Suggestion: [how to replace] > > If no reuse issues are found, report: "No reuse issues found."

Agent 2: Code Quality Review

Provide this prompt to the agent:

> You are reviewing a code diff for quality issues. Your job is to find hacky patterns, unnecessary complexity, and abstraction boundary violations. > > Check for these patterns: > > 1. **Redundant state:** new variables that are always derived from another variable, caches that store what could be computed on access, event listeners or observers that could be direct function calls. > 2. **Parameter sprawl:** functions that gained a new boolean flag parameter, functions with more than 4 parameters after the change, multiple parameters that are always passed together and should be a single object. > 3. **Copy-paste with slight variation:** two or more blocks that differ by only 1-2 lines, repeated conditional structures with different field names, similar error handling blocks across multiple locations. > 4. **Leaky abstractions:** accessing private fields or internal state from outside the module, passing implementation details across module boundaries, changes that make one module depend on another's internal structure. > 5. **Stringly-typed code:** new string comparisons against values already defined as constants, new string literals matching existing enum or union type values, magic strings appearing in multiple places without a shared constant. > 6. **Unnecessary comments:** comments explaining WHAT the code does, narrating the change, or referencing a task. Delete these. Keep only comments that explain non-obvious WHY — hidden constraints, subtle invariants, workaround