# Code Review

> Reviews pull request diffs for correctness, security, maintainability, and test coverage, providing severity-ranked findings and a close-out recommendation.

- Skill: `rosendolu/code-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add rosendolu/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rosendolu/code-review/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security, Coding & Dev Tools, Code Review, Secure Coding
- Tags: Code Review, Diff, Maintainability, Pull Request, Security Audit, Test Coverage
- Author: rosendolu (https://skillmd.com/u/rosendolu)
- Updated: 2026-08-22
- Page: https://skillmd.com/skills/rosendolu/code-review

---


# 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:

```text
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.