claude-simplify git:20260925.32ce6c0A

Immutable. This exact content never changes and is served at /api/v1/blob/914e3b25d616d387.

---
name: claude-simplify
description: "Review changed code for reuse, quality, and efficiency, then fix the issues found by launching three parallel review agents (reuse, quality, efficiency) over the diff. Use after completing a feature or bugfix, before committing or opening a PR, or whenever the user asks to simplify, clean up, or optimize recent changes. Trigger phrases: \"simplify this\", \"review my changes\", \"clean up the code\", \"check for issues\", \"refactor\", \"code review\", \"optimize\", 「审查我的改动」「清理代码」「简化代码」「检查有没有问题」「代码审查」."
allowed-tools: ["Read", "Grep", "Glob", "Edit", "Bash", "Agent"]
argument-hint: "[optional focus area]"
---

# Simplify: Code Review and Cleanup

## Purpose

Turn a freshly written change set into a cleaner one. It runs three independent review
lenses over the diff — reuse, quality, efficiency — aggregates their findings, and applies
the fixes directly, so the output is improved code plus a short account of what changed.

## When to Use

- Immediately after finishing a feature, bugfix, or refactor, before committing.
- The user asks to simplify, clean up, review, or optimize the code they just wrote.
- A diff is about to become a PR and needs a quality pass first.
- Trigger phrases: "simplify this", "review my changes", "clean up the code",
  "check for issues", "refactor", "code review", "optimize"; 「审查我的改动」「清理代码」
  「简化代码」「代码审查」.

## When NOT to Use

- The user wants the **diff explained**, not changed -> answer directly, run no agents.
- The request is a **repo-wide audit of unchanged code** -> scope here is the diff only;
  review the touched code or hand off to a broader audit skill.
- The request is a **security review** of untrusted third-party code -> hand off to
  `skill-security-check`.
- The user wants **new functionality or a redesign**, not cleanup -> that is a feature task,
  not this skill.

## Workflow

1. **Identify the changes.** Run `git diff` (use `git diff HEAD` when changes are staged).
   If there is no git diff, review the files the user named or that you edited earlier in
   this conversation.
2. **Launch the three review agents in parallel.** In a single message, start the reuse,
   quality, and efficiency agents and give each the full diff plus its checklist from
   `references/review-checklists.md`.
3. **Wait for all three** to finish, then aggregate their findings into one list.
4. **Fix each issue directly.** Skip false positives and low-value findings silently — note
   them, do not argue.
5. **Summarize** what was fixed, what was flagged but deliberately skipped, and confirm when
   the code was already clean.

## Decision Rules

- No git changes at all -> review the most recently modified files the user mentioned; never
  invent a diff.
- A finding is a false positive or not worth addressing -> skip it and record it in the
  summary; do not debate the reviewer.
- A finding touches the changed lines or their immediate helpers -> fix it in place.
- A finding would require changing unrelated, pre-existing code -> report it instead of
  editing (see Priority).
- The same problem is reported by more than one agent -> fix once, list it once.
- User gave a focus area via `argument-hint` -> weight that lens, but still run all three.

## Constraints

- Pass the **full diff** to every agent; a truncated diff produces shallow findings.
- Launch the three agents **in one message** so they run concurrently.
- Fix issues; do not merely report them, unless Priority says otherwise.
- Do not modify code outside the reviewed change set.
- Never revert changes you did not make and were not asked to touch.

## Priority

1. **Do not damage unrelated work.** If a fix would alter pre-existing code beyond the diff,
   report it and leave the code alone.
2. **Apply fixes that are contained in the diff** and its immediate helpers.
3. **Cover all three lenses** before declaring the review done; do not stop after the first
   agent returns findings.

## Verification

- [ ] The review scope equals the actual diff (or the named files when no diff exists).
- [ ] All three agents ran against the full diff.
- [ ] Every accepted finding is either fixed or explicitly listed as skipped with a reason.
- [ ] No file outside the reviewed change set was modified.
- [ ] The final summary covers found-and-fixed, skipped, and (if applicable) already-clean.

## Output

- **Outcome**: the changed code updated in place, plus a short summary of the review.
- **Done when**: all three agents have returned, their findings are resolved or explicitly
  skipped, and the summary is delivered.
- **Evidence**: the summary listing found/fixed issues, intentionally skipped findings with
  reasons, and a clean-code confirmation when nothing was found.

## References

Load only when needed:

- `references/review-checklists.md` — read when launching the three review agents, to get
  each agent's checklist; also read when the user asks what the review inspects.

## Related Skills

- `clean-code` — the underlying smell taxonomy and refactoring catalogue behind the quality
  lens; consult it when a finding needs justification.
- `skill-security-check` — use instead when the code under review is untrusted or
  third-party.