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.