code-review

Code Review

A code review skill that checks for web security vulnerabilities, performance issues, accessibility problems, and code quality — then delivers structured feedback with severity levels.

Instructions

STEP 1 — GATHER CHANGES

Determine what to review:

• If a GitHub PR URL is provided: fetch the PR diff and context
• If a branch name is provided: diff it against the main branch
• If file paths are provided: read those files directly
• If nothing is provided: check for staged changes, then fall back to unstaged changes

STEP 2 — ANALYZE

Review the changes across these dimensions:

Security (OWASP Top 10):

• Injection flaws (SQL, XSS, command injection)
• Broken authentication / authorization
• Sensitive data exposure (hardcoded secrets, API keys, tokens)
• Insecure dependencies (check for known CVEs if possible)
• CSRF, open redirects (including client-side navigation to unvalidated URLs), unsafe deserialization

Performance:

• Unnecessary re-renders (React: missing memo, unstable refs in deps, missing key props in lists)
• Bundle size impact (large imports, tree-shaking issues)
• N+1 queries, unoptimized loops, missing pagination
• Memory leaks (event listeners, subscriptions not cleaned up)
• Lazy loading opportunities

Accessibility:

• Missing ARIA attributes, roles, or labels
• Keyboard navigation issues
• Color contrast, focus management
• Semantic HTML usage

Code Quality:

• Type safety issues (TypeScript)
• Error handling gaps
• Dead code, unused imports
• Naming clarity, readability
• Test coverage for new logic

STEP 3 — REPORT

Output the review in this format:

## Code Review

### Summary
[1-2 sentence overview of the changes and overall assessment]

### Findings

#### 🔴 Critical
[Issues that MUST be fixed before merging — security vulnerabilities, data loss risks, breaking bugs]

#### 🟡 Warning
[Issues that SHOULD be fixed — performance problems, accessibility gaps, potential bugs]

#### 🔵 Suggestion
[Nice-to-haves — code style improvements, minor optimizations, better patterns]

#### ✅ Good
[Things done well worth calling out — encouragement for good patterns]

### Verdict: [APPROVE | REQUEST CHANGES | NEEDS DISCUSSION]

Rules

• Every finding must reference the specific file and line number. If code is provided inline (not from a file), reference the relevant line within the snippet
• Include a concrete fix or code suggestion for each Critical and Warning item
• If there are no findings in a severity category, omit that category
• Be direct and specific — no vague feedback like "consider improving this"
• If the diff is clean with no issues, say so and approve
• For security findings, explain the attack vector briefly so the author understands the risk