claude-simplify · diff
git:20260402.688aaa4 to git:20260925.32ce6c0
81 added, 40 removed. Audit A to A.
---
name: claude-simplify
- description: Review changed code for reuse, quality, and efficiency, then fix any issues found.
+ 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"]
- when_to_use: |
- Use when the user wants to review and improve code quality after making changes.
- Trigger phrases: "simplify this", "review my changes", "clean up the code",
- "check for issues", "refactor", "code review", "optimize".
- Run after completing a feature or bugfix to ensure code quality.
argument-hint: "[optional focus area]"
---
# Simplify: Code Review and Cleanup
- Review all changed files for reuse, quality, and efficiency. Fix any issues found.
+ ## Purpose
- ## Phase 1: Identify Changes
+ 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.
- Run `git diff` (or `git diff HEAD` if there are staged changes) to see what changed. If there are no git changes, review the most recently modified files that the user mentioned or that you edited earlier in this conversation.
+ ## When to Use
- ## Phase 2: Launch Three Review Agents in Parallel
+ - 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"; 「审查我的改动」「清理代码」
+ 「简化代码」「代码审查」.
- Use the Agent tool to launch all three agents concurrently in a single message. Pass each agent the full diff so it has the complete context.
+ ## When NOT to Use
- ### Agent 1: Code Reuse Review
+ - 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.
- For each change:
+ ## Workflow
- 1. **Search for existing utilities and helpers** that could replace newly written code. Look for similar patterns elsewhere in the codebase — common locations are utility directories, shared modules, and files adjacent to the changed ones.
- 2. **Flag any new function that duplicates existing functionality.** Suggest the existing function to use instead.
- 3. **Flag any inline logic that could use an existing utility** — hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards, and similar patterns are common candidates.
+ 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.
- ### Agent 2: Code Quality Review
+ ## Decision Rules
- Review the same changes for hacky patterns:
+ - 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.
- 1. **Redundant state**: state that duplicates existing state, cached values that could be derived, observers/effects that could be direct calls
- 2. **Parameter sprawl**: adding new parameters to a function instead of generalizing or restructuring existing ones
- 3. **Copy-paste with slight variation**: near-duplicate code blocks that should be unified with a shared abstraction
- 4. **Leaky abstractions**: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
- 5. **Stringly-typed code**: using raw strings where constants, enums (string unions), or branded types already exist in the codebase
- 6. **Unnecessary JSX nesting**: wrapper Boxes/elements that add no layout value — check if inner component props (flexShrink, alignItems, etc.) already provide the needed behavior
- 7. **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)
+ ## Constraints
- ### Agent 3: Efficiency Review
+ - 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.
- Review the same changes for efficiency:
+ ## Priority
- 1. **Unnecessary work**: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns
- 2. **Missed concurrency**: independent operations run sequentially when they could run in parallel
- 3. **Hot-path bloat**: new blocking work added to startup or per-request/per-render hot paths
- 4. **Recurring no-op updates**: state/store updates inside polling loops, intervals, or event handlers that fire unconditionally — add a change-detection guard so downstream consumers aren't notified when nothing changed
- 5. **Unnecessary existence checks**: pre-checking file/resource existence before operating (TOCTOU anti-pattern) — operate directly and handle the error
- 6. **Memory**: unbounded data structures, missing cleanup, event listener leaks
- 7. **Overly broad operations**: reading entire files when only a portion is needed, loading all items when filtering for one
+ 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.
- ## Phase 3: Fix Issues
+ ## Verification
- Wait for all three agents to complete. Aggregate their findings and fix each issue directly. If a finding is a false positive or not worth addressing, note it and move on — do not argue with the finding, just skip it.
+ - [ ] 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.
- When done, briefly summarize:
- 1. What issues were found and fixed
- 2. Any issues that were flagged but intentionally skipped (and why)
- 3. Confirmation if the code was 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.