| name | code-review |
| description | Structured code review workflow and security checks |
Code Review Process
Follow these steps when reviewing pull requests. This skill provides a
consistent, thorough review process covering correctness, security,
performance, and maintainability.
Prerequisites
- Access to the repository and the PR diff.
- Familiarity with the project's coding standards.
- The security checklist at
references/security-checklist.md.
Step 1 — Understand Context
- Read the PR title, description, and linked tickets.
- Understand the intent — what problem does this solve?
- Check the size of the diff. If it's > 400 lines, consider asking the
author to split it into smaller, reviewable chunks.
Step 2 — Automated Checks
Before diving into code, verify:
If any automated check fails, leave a comment asking the author to fix
before continuing the manual review.
Step 3 — Security Review
Consult the Security Checklist for a comprehensive list of items:
Reference: Read the Security Checklist
for the full OWASP-aligned checklist.
Key items to spot-check:
- Hardcoded secrets or API keys.
- Unsanitised user input (XSS, SQLi, SSRF vectors).
- Missing authorization checks on new endpoints.
- Overly permissive CORS or CSP headers.
Step 4 — Logic & Performance
- Look for algorithmic inefficiencies — O(n²) loops, unnecessary
database queries inside loops, unbounded list fetches.
- Check for memory leaks — event listeners not cleaned up, growing
caches without eviction.
- Verify error handling — are exceptions caught and logged? Are
retries bounded?
- Confirm edge cases — empty inputs, null values, very large inputs.
Step 5 — Readability & Maintainability
- Are variable and function names descriptive?
- Is there adequate documentation for public APIs?
- Are complex algorithms explained with comments?
- Is dead code removed?
Step 6 — Leave Feedback
Use these prefixes to categorise your comments:
| Prefix | Meaning |
|---|
Blocker: | Must be fixed before merge |
Suggestion: | Recommended but not blocking |
Nit: | Style/formatting — optional |
Question: | Seeking clarification from the author |
Praise: | Something done well — reinforce good patterns |
Decision Guide
- If no blockers → Approve the PR.
- If blockers exist → Request changes with clear descriptions.
- If unsure → Add a
Question: comment and request a second reviewer.
