name: code-review description: Reviews pull request diffs for correctness, security, maintainability, and test coverage. Use when the user asks for a code review of a change set, patch, or PR description.

Code Review

Instructions

When reviewing a diff/PR, follow this flow:

1. Clarify context (if missing)

   • Ask for the repo name, language/framework, and what “done” means (e.g., “ready to merge” vs “early review”).
   • If the user did not provide a diff, ask them to paste the relevant patch or describe the files/behavior changed.

2. Summarize the change

   • Provide a 2–5 sentence summary of what changed and the most important impact.

3. Identify issues with severity

   • Report issues in this order: Critical, Suggestion, Nice-to-have.
   • For each issue, include: severity, area (correctness/security/performance/maintainability/tests/style), location (file path and the changed symbol/section when possible), and why it matters.
   • Prefer specific, actionable fixes over general guidance.

4. Security review

   • Check for common risks relevant to the language/framework: injection (SQL/NoSQL/command), XSS/CSRF, authz/authn mistakes, unsafe deserialization, SSRF, secrets in logs, and overly-permissive CORS.
   • If user input handling exists, validate, sanitize/escape appropriately, and enforce allow-lists where possible.

5. Correctness & robustness

   • Look for broken invariants, edge cases, race conditions, timezone/locale bugs, error handling, and inconsistent data types.
   • Verify new/modified code paths are exercised by the change.

6. Maintainability

   • Check naming, complexity, duplication, API boundaries, and whether abstractions match existing patterns.
   • Flag “spaghetti logic” or overly broad functions/modules.

7. Tests & quality gate

   • Identify missing/weak tests that would have caught the issues you found.
   • If the repo has test tooling detectable from the diff (e.g., jest, vitest, pytest, go test, npm test), suggest the most likely command(s) to run.
   • If you cannot infer a command reliably, list what to test instead (unit/integration/E2E) without guessing exact commands.

8. Close-out recommendation

   • End with a short decision suggestion: “Approve”, “Request changes”, or “Needs follow-up” based on Critical items.

Output Template

Use this structure by default:

Summary
- ...

Critical
- [file/path] <what> — <why> — Fix: <specific change>

Suggestion
- [file/path] <what> — <why> — Fix: <specific change>

Nice-to-have
- [file/path] <what> — <why> — Improvement: <specific change>

Test plan (what to run / what to add)
- ...

Recommendation
- Approve / Request changes / Needs follow-up

Standards

• If the repo contains a style guide or security guidelines (commonly docs/STYLE.md, STYLE_GUIDE.md, SECURITY.md, or CONTRIBUTING.md), align findings and fix suggestions to those documents.