simplify
Simplify
Reviews all changed files through three parallel agents — reuse, quality, and efficiency — then fixes any issues found.
Core Principle
Changed code is the only review target. Each review dimension runs independently, sees the full diff, and reports findings without knowledge of the other agents' results. The main agent aggregates and applies fixes.
Hard Gates
- Identify changes before reviewing. Always run
git diff(orgit diff HEADif there are staged changes) first. Never review without knowing what changed. - All three agents must run in parallel. Sequential execution of the three review agents is prohibited. Dispatch all three concurrently in a single message.
- Each agent receives the full diff. Do not split or filter the diff per agent. Every agent sees every change.
- Fix issues directly. This skill produces code changes, not just a report. If a finding is actionable, fix it.
- Skip false positives silently. If a finding is not worth addressing, move on. Do not argue with the finding or explain why it was skipped.
- Do not expand scope beyond the diff. Review only the changed code. Do not refactor untouched code, even if it has the same issues.
When To Use
More from tmdgusya/engineering-discipline
clarification
Use when a user's request is vague, ambiguous, or underspecified. Launches an iterative Q&A loop to resolve ambiguity while a subagent explores the codebase in parallel. Outputs a clear, well-scoped context brief so the user can plan sharply. Triggers on "I want to...", "I need...", "let's build...", "can you help me...", "we should...", or any request where the full scope isn't immediately clear.
36rob-pike
Rob Pike's 5 Rules of Programming — a decision framework that prevents premature optimization and enforces measurement-driven development. Use when the user says "optimize", "slow", "performance", "bottleneck", "speed up", "make faster", "too slow", or any request to improve code speed/efficiency. Also use when you notice yourself about to suggest a performance optimization without measurement data. This is a thinking discipline, not a tooling workflow.
35run-plan
Use when you have a written implementation plan to execute. Loads the plan, reviews critically, executes tasks in dependency order, and reports completion. Triggers when the user says "run the plan", "execute the plan", or "let's start implementing".
35systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior. Enforces a strict reproduce-first, root-cause-first, failing-test-first debugging workflow before fixing.
33plan-crafting
Use when a task's scope is clear and multi-step implementation is needed, before touching code. Triggered after clarification is complete, or when the user explicitly requests plan creation with a clear prompt.
32long-run
Orchestrates multi-day execution of complex tasks through milestones. Each milestone goes through plan-crafting, run-plan (worker-validator), and review-work phases with checkpoint/recovery. Triggers when the user says "long run", "start long run", "execute milestones", or "run all milestones".
30