Simplify

---
name: simplify
description: >-
  Review changed code for reuse, quality, and efficiency, then clean up what you
  find — duplicated logic that could reuse an existing helper, hacky or redundant
  patterns, needless work on hot paths. Quality cleanup only: not bugs (that's
  code-review) and not behavior-preserving restructuring on request (that's
  refactor). Use when the user says "simplify", "clean this up", "is there a
  simpler way", or "tidy the diff".
allowed-tools:
  - Bash
  - Read
  - Glob
  - Grep
  - Edit
  - Agent
argument-hint: "[focus area]"
---

# Simplify: quality cleanup on the changed code

Review the changed code for cleanups it would benefit from, then apply them. This
is the **quality** pass — reuse, hacky patterns, wasted work. It is not the bug
pass (`code-review`) and not a requested restructuring (`refactor`); stay in its
lane and don't report correctness bugs or propose structural rewrites here.

## Phase 1: Identify changes

Run `git diff` (or `git diff HEAD` when changes are staged). With no git changes,
review the most recently modified files the user named or that you edited earlier
in this conversation.

## Phase 2: Review across three lenses (in parallel)

Use the Agent tool to launch three reviewers concurrently in one message
(foreground). Give each the full diff. Each returns a short list of concrete,
located findings.

- **Reuse.** New code that duplicates an existing helper or utility; hand-rolled
  logic (string munging, path handling, env checks, type guards) that the
  codebase already has a function for. Point to the existing one to use instead.
- **Quality.** Redundant state that could be derived; parameter sprawl instead of
  restructuring; near-duplicate blocks that should share an abstraction; leaky
  abstractions; stringly-typed code where a constant/enum exists; needless wrapper
  layers; conditionals nested 3+ deep (flatten with early returns or a lookup);
  comments that narrate WHAT instead of non-obvious WHY.
- **Efficiency.** Redundant computation or repeated reads; independent work run
  sequentially that could be parallel; new blocking work on a startup or
  per-request hot path; unconditional no-op updates in loops/handlers (guard with
  change detection); pre-checking existence before operating (TOCTOU); unbounded
  growth or leaked resources; reading/loading far more than needed.

## Phase 3: Apply the cleanups

Aggregate the findings and fix each directly. Keep each fix minimal and matched to
the file's existing style. If a finding is a false positive or not worth it, skip
it — don't argue with it. When done, briefly summarize what you cleaned up, or
confirm the code was already clean.