simplify-code
Simplify Code
Review code for reuse, quality, efficiency, and clarity issues, then fix them.
Step 1: Determine the Scope
Determine what to review:
- If a specific diff command was provided (e.g.,
git diff --cached), use that. - If a file list or directory was provided, review those files directly (read the full files, not a diff).
- If neither was provided, determine the appropriate diff command (e.g.,
git diff,git diff --cached,git diff HEAD) based on the current git state. If there are no git changes, review the most recently modified files mentioned in the conversation.
Step 2: Launch Four Review Agents in Parallel
Use the Agent tool to launch all four agents below in a single assistant message so they run concurrently. Each Agent call uses model: "opus" and does not set run_in_background. Pass the scope from Step 1 to each agent.
Agent 1: Code Reuse Review
For each change:
- 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.
- Flag any new function that duplicates existing functionality. Suggest the existing function to use instead.
- Flag any inline logic that could use an existing utility — hand-rolled string manipulation, manual path handling, custom environment checks, and similar patterns are common candidates.
Agent 2: Code Quality Review
Review the same changes for hacky patterns:
- Redundant state: state that duplicates existing state, cached values that could be derived, reactive subscriptions that could be direct calls
- Parameter sprawl: adding new parameters to a function instead of generalizing or restructuring existing ones
- Copy-paste with slight variation: near-duplicate code blocks that should be unified with a shared abstraction
- Leaky abstractions: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
- Stringly-typed code: using raw strings where constants, enums, or dedicated types already exist in the codebase
- Unnecessary wrapper nesting: container elements or wrapper layers that add no structural or layout value
Agent 3: Efficiency Review
Review the same changes for efficiency:
- Unnecessary work: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns
- Algorithmic complexity: nested iterations, repeated linear searches replaceable by sets/maps, missing early exits
- Missed concurrency: independent operations run sequentially when they could run in parallel
- Hot-path bloat: new blocking work added to startup or per-request hot paths
- Unnecessary existence checks: pre-checking file/resource existence before operating (TOCTOU anti-pattern) — operate directly and handle the error
- Memory: unbounded data structures, missing cleanup, resource leaks
- Overly broad operations: reading entire files when only a portion is needed, loading all items when filtering for one
Agent 4: Clarity and Standards Review
Review the same changes for clarity, standards, and balance:
- Project standards: coding conventions from CLAUDE.md not followed — import sorting, naming conventions, component patterns, error handling patterns, module style
- Unnecessary complexity: deep nesting, redundant abstractions, unclear variable or function names, comments that describe obvious code, nested ternary operators (prefer switch/if-else chains), redundant boolean comparisons (e.g.,
x == trueinstead ofx) - Unclear code: choose clarity over brevity — explicit code is better than overly compact code. Consolidate related logic, but not at the cost of readability
- Over-simplification: overly clever solutions that are hard to understand, too many concerns combined into single functions or components, "fewer lines" prioritized over readability (dense one-liners, nested ternaries), helpful abstractions removed that were aiding code organization
- Dead weight: unnecessary comments, redundant code, abstractions that add indirection without value
Step 3: Fix Issues
Wait for all four agents to complete. Aggregate their findings, then apply each fix directly, skipping false positives.
When done, briefly summarize what was fixed (or confirm the code was already clean).
Then use the TaskList tool and proceed to any remaining task.
More from tobihagemann/turbo
find-dead-code
Find dead code using parallel subagent analysis and optional CLI tools, treating code only referenced from tests as dead. Use when the user asks to \"find dead code\", \"find unused code\", \"find unused exports\", \"find unreferenced functions\", \"clean up dead code\", or \"what code is unused\". Analysis-only — does not modify or delete code.
30smoke-test
Launch the app and hands-on verify that it works by interacting with it. Use when the user asks to \"smoke test\", \"test it manually\", \"verify it works\", \"try it out\", \"run a smoke test\", \"check it in the browser\", or \"does it actually work\". Not for unit/integration tests.
22finalize
Run the post-implementation quality assurance workflow including tests, code polishing, review, and commit. Use when the user asks to \"finalize implementation\", \"finalize changes\", \"wrap up implementation\", \"finish up\", \"ready to commit\", or \"run QA workflow\".
22self-improve
Extract lessons from the current session and route them to the appropriate knowledge layer (project AGENTS.md, auto memory, existing skills, or new skills). Use when the user asks to \"self-improve\", \"distill this session\", \"save learnings\", \"update CLAUDE.md with what we learned\", \"capture session insights\", \"remember this for next time\", \"extract lessons\", \"update skills from session\", or \"what did we learn\".
22evaluate-findings
Critically assess external feedback (code reviews, AI reviewers, PR comments) and decide which suggestions to apply using adversarial verification. Use when the user asks to \"evaluate findings\", \"assess review comments\", \"triage review feedback\", \"evaluate review output\", or \"filter false positives\".
22investigate
Systematically investigate bugs, test failures, build errors, performance issues, or unexpected behavior by cycling through characterize-isolate-hypothesize-test steps. Use when the user asks to \"investigate this bug\", \"debug this\", \"figure out why this fails\", \"find the root cause\", \"why is this broken\", \"troubleshoot this\", \"diagnose the issue\", \"what's causing this error\", \"look into this failure\", \"why is this test failing\", or \"track down this bug\".
21