Simplify — parallel review, sequential apply

Spawns three focused review subagents in parallel, each returning a list of suggested edits. The main agent then applies them sequentially, resolving conflicts deterministically using the Principles below. The skill is non-interactive: it never stops to ask the user. When the Principles don't pick a clear winner, the finding is logged as "not applied" rather than surfaced as a question — the user reads the final report and re-engages if they want one of the rejected proposals.

Why review-then-apply and not apply-in-parallel: if three subagents Edit the same files concurrently, they race. Late writers either fail loudly (Edit's old_string mismatch) or — worse — see "my change is already there" and silently skip, so most findings get dropped. Parallelizing the slow part (analysis) while serializing writes gives both speed and correctness.

If $ARGUMENTS contains a focus hint (e.g. "memory efficiency"), pass it through to all three subagents so they weight that dimension.

Principles every reviewer must follow

These are cross-cutting — they apply to every finding regardless of reviewer category. The main agent passes them into each reviewer's prompt.

Preserve behavior. Any change to return values, exceptions, edge-case handling, or observable side effects is a behavior change, not a simplification. If a refactor alters output for any input — even malformed or "invalid" input the original happened to accept — it's not a cleanup, it's a redesign. Don't propose those as simplifications; if you spot one and think it's worth doing, label it explicitly so the user can decide.
Clarity over brevity. Fewer lines is not the goal; a reader understanding the code at a glance is. Avoid nested ternaries when if/elif/else reads clearer. Don't wrap trivial operations in named helpers just to "reuse" something — multiplyTwoNumbers(n, n) is worse than n * n, not better. A short dense one-liner is worse than a two-line form a reader can follow on first pass.
Respect house conventions. If the session's CLAUDE.md documents style rules or idiom preferences, they win over generic idioms — a reviewer suggesting f-strings is wrong if CLAUDE.md says use .format(). CLAUDE.md is the canonical place for project rules; subagents already see it in context, so no manual passthrough is needed.

Phase 1 — Capture changes

Run git status --short to surface untracked new files (no diff command shows these).
Run git diff HEAD to capture unstaged + staged changes to tracked files.
If the diff is empty, run git diff against the merge-base. If still empty, fall back to recently modified or mentioned files in the current session.
For each untracked file from step 1, read its full contents and append as a synthetic +++ block so the subagents see new files as additions.
If the combined diff is under ~20 lines AND covers a single concern, skip Phase 2 and just dispatch the most relevant single reviewer. Three reviewers on a six-line diff is overkill and produces noise.

Phase 2 — Launch THREE reviewers IN PARALLEL

Dispatch three Agent tool calls in a single message. All use:

subagent_type: "general-purpose"
model: "sonnet" — pin so cost stays predictable across parent session models

Each reviewer receives the full diff and the focus hint (if any), and returns proposed edits as JSON. Reviewers do NOT call Edit. They report; the main agent applies.

Required return format

Each reviewer must end its response with a fenced JSON block:

{
  "findings": [
    {
      "file": "absolute/path/to/file",
      "old_string": "exact text to replace (must be unique in the file or include enough context to be unique)",
      "new_string": "replacement text",
      "rationale": "one short sentence — what was wrong, why this is better",
      "confidence": "high" | "medium" | "low"
    }
  ]
}

Empty findings → {"findings": []}. Don't pad.

1 — Code Reuse Reviewer

Review the following diff for missed reuse opportunities. Search the WIDER codebase (not just the diff) using Grep to find:

New functions that duplicate existing utilities or helpers

Inline logic that should use existing utilities: hand-rolled string manipulation, manual path handling, custom env checks, ad-hoc type guards

Similar patterns in utility directories, shared modules, and adjacent files

Principles (apply to every finding):

Preserve behavior. If your proposed change alters return values, exceptions, side effects, or edge-case handling for any input — including malformed input — it's a redesign, not a simplification. Don't propose it as a cleanup; if worth doing, flag it as a behavior change. Treat the diff's deleted (-) lines as the behavior baseline — restoring the behavior of a deleted line (e.g. reverting an added == True to a plain truthiness check) is not a behavior change.

Clarity > brevity. Wrapping n * n in multiplyTwoNumbers(n, n) is not reuse, it's worse code. Only propose reuse when the existing helper genuinely captures a non-trivial pattern.

Respect house conventions. Project conventions (below) override generic idioms.

Do NOT use Edit, Write, or any file-modification tool. Your job is to propose edits, not apply them. Return findings as a JSON block per the schema above. Skip false positives silently.

FOCUS HINT: {hint or "none"}

DIFF: {paste full diff here}

2 — Code Quality Reviewer

Review the following diff for quality issues. Look for:

Redundant state: state duplicating existing state, cached values that could be derived, observers/effects that could be direct calls

Parameter sprawl: new parameters added instead of generalizing or restructuring

Copy-paste with slight variation: near-duplicate blocks that should share an abstraction

Leaky abstractions: exposing internals, breaking existing abstraction boundaries

Stringly-typed code: raw strings where constants, enums, or branded types already exist

Verbose patterns: unnecessary intermediate variables, == true/== false, redundant else after return, multi-check null guards that collapse to one expression

Unnecessary JSX nesting: wrapper Boxes/elements that add no layout value — check if inner component props (flexShrink, alignItems, etc.) already provide the needed behavior

Nested conditionals: ternary chains (a ? x : b ? y : ...), nested if/else, or nested switch 3+ levels deep — flatten with early returns, guard clauses, a lookup table, or an if/else-if cascade

Unnecessary comments: comments explaining WHAT the code does (well-named identifiers already do that), narrating the change, or referencing the task/caller — delete; keep only non-obvious WHY (hidden constraints, subtle invariants, workarounds)

Principles (apply to every finding):

Preserve behavior. If your refactor alters return values, exceptions, side effects, or edge-case handling for any input, it's a behavior change — flag it as such, don't dress it up as a cleanup. Treat the diff's deleted (-) lines as the behavior baseline — restoring the behavior of a deleted line (e.g. reverting an added == True to a plain truthiness check) is not a behavior change.

Clarity > brevity. Don't trade readability for fewer lines. Nested ternaries, dense one-liners, chained mystery operators are not improvements over clear if/else blocks. A reader should grok the rewrite faster than the original.

Respect house conventions. Project conventions (below) override generic idioms.

Do NOT use Edit, Write, or any file-modification tool. Your job is to propose edits, not apply them. Return findings as a JSON block per the schema above.

FOCUS HINT: {hint or "none"}

DIFF: {paste full diff here}

3 — Efficiency Reviewer

Review the following diff for efficiency issues. NO premature opt

simplify