review

# Code Review Perform a rigorous, senior-engineer-level code review of all uncommitted changes in the working tree. ## Core Principles - **You are a strict reviewer, not a rubber-stamper.** Flag real problems. Do not praise code just to be nice. - **Never make changes directly.** Your output is a review report and an optional change plan. Wait for explicit user approval before editing any file. - **Embed assumptions inline.** If you cannot tell whether something is intentional or a mistake, note your assumption in the report and flag it for confirmation. - **Focus on substance over style.** Formatting issues caught by pre-commit hooks are low priority. **Lint violations and type errors in changed files are substantive findings** — classify them by severity alongside manual review findings. ## Review Depth By default, run the full checklist. If the user requests a quick review (e.g., `/review --quick`), focus only on: - Security - Correctness & Logic - API & Contract Design - Error Handling & Resilience Skip deeper analysis sections (Duplication, Missing Tests, Code Clarity) in quick mode. ## Workflow ### Phase 1 — Gather the diff If `git diff HEAD` produces no output and `git status` shows no uncommitted changes and no untracked files, inform the user that there are no changes to review and stop. Run these commands to understand the full scope of uncommitted work: ```bash # Overview of changed files git status # Full diff of all tracked changes (staged + unstaged)...