code-review

# Code Review ## When to use - User pastes code in chat - User attaches a code file - User asks for review, audit, "find bugs", "security check" ## Steps 1. **Identify scope and language** — what's being reviewed, in what language? If multiple files involved, ask which to focus on first via `ask_questions`. 2. **Read the code carefully** — don't skim. For files in `fs`, call `fs_read`. 3. **Categorise findings**: - **Bugs** (incorrect behaviour, will fail at runtime) - **Security** (injection, auth bypass, exposed secrets, unsafe deserialization) - **Performance** (N+1 queries, unnecessary loops, blocking ops) - **Reliability** (missing error handling, race conditions, resource leaks) - **Style** (naming, formatting, idiomatic patterns) - **Design** (architecture, coupling, complexity) 4. **Filter ruthlessly** — only report issues you're confident about. Skip: - Style nits if the user asked about bugs - Theoretical problems with no evidence in this code - Personal preferences disguised as best practices 5. **For each finding, provide**: - **Severity**: critical / high / medium / low - **Line reference** if available - **What's wrong** (one sentence) - **Why it matters** (one sentence) - **Suggested fix** (code snippet) 6. **Display the findings**: - For 1-3 findings: render inline as markdown - For more: use `show_data_table` with columns: Severity, Line, Issue, Fix - Use `show_alert` (`error` type) for any critical findings at the top 7. **Summarise** — one paragraph: overall code quality, biggest concern, recommended next action. 8. **Offer next steps** via `offer_choices`: - "Apply the critical fix" - "Show me how to test this" - "Review another file" - "Explain finding [N]" ## Style - Direct but not harsh. Critique the code, not the coder. - Show, don't tell — code suggestions speak louder than abstract advice. - Acknowledge what's good if there are bright spots. ## What not to do - Don't make up issues to seem thorough - Don't suggest sweeping rewrites unless asked - Don't mix style nits with critical bugs in the same list (separate by severity) - Don't claim certainty about runtime behaviour you can't verify (note assumptions) ## Optional: actually run the code If `run_python` or `run_shell` tools are available and the code is safe to execute, run it with the user's permission to verify: - Does it execute without errors? - Does the output match expected behaviour? Use `confirm_action` first: "Should I run this code in the sandbox to test it?"