How do I install the Code Review skill?

Run npx skillmds@latest add shyamw-cloud/code-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Code Review safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Code Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Code Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Code Review?

shyamw-cloud (@shyamw-cloud) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Code Review by shyamw-cloud — Agent Skill

Name: Code Review
Rating: 4.2 (5 reviews)
Author: shyamw-cloud

Code Review

Use to review a pull request or a diff. Produces severity-tagged comments ([blocker], [suggestion], [nit]), one summary verdict, and a security pass. Reads adjacent files to verify claims and never hand-waves "looks good."

shyamw-cloud Updated Sep 22, 2026

File contents

code-review

A useful review answers four questions:

Does it work? Does the change actually do what the PR description says?
Is it safe? Any security, data-loss, or backwards-compat risk?
Is it maintainable? Will the next person to read this in 6 months understand it?
Is it the smallest change that solves the problem?

Method

Read the PR description. Note the stated goal.
Read the diff in full.
Read adjacent files for any function/class touched (callers, tests, types).
Run the tests if you can. If you can't, say so.
Group findings by severity.

Severity tags

[blocker] — must be fixed before merge. Bug, security issue, breaks tests, breaks API.
[suggestion] — should probably be fixed. Smell, missing test, unclear name.
[nit] — purely cosmetic. Author can ignore.
[question] — you genuinely don't understand and need an answer to finish reviewing.

Security pass — always do these

Are user inputs validated at the boundary?
Are secrets out of the diff (no hardcoded keys)?
Are SQL queries parameterized?
Are auth checks present on new endpoints?
Are file paths normalized (no path traversal)?
Are dependencies pinned and from a trusted source?

Output format

## Verdict
<approve | request changes | comment>

## Summary
<2-3 sentences: what the PR does, what's good, what's blocking.>

## Findings

### [blocker] <file:line>
<what's wrong>
<suggested fix>

### [suggestion] <file:line>
<what could be better>

### [nit] <file:line>
<cosmetic>

### [question] <file:line>
<what you don't understand>

## Security pass
- [x] inputs validated
- [x] no secrets
- [x] queries parameterized
- [ ] auth checks — see [blocker] above
- [x] paths safe
- [x] deps clean

## Tests
- [x] PR includes a test for the new behavior
- [x] tests pass locally / in CI

Hard rules

Never approve a PR you didn't read. Never approve a PR with a failing CI.
Never tag something [blocker] without proposing a concrete fix.
Be kind. Critique the code, not the coder.

---name: code-reviewdescription: Use to review a pull request or a diff. Produces severity-tagged comments ([blocker], [suggestion], [nit]), one summary verdict, and a security pass. Reads adjacent files to verify claims and never hand-waves "looks good."---# code-reviewA useful review answers four questions:1. **Does it work?** Does the change actually do what the PR description says?2. **Is it safe?** Any security, data-loss, or backwards-compat risk?3. **Is it maintainable?** Will the next person to read this in 6 months understand it?4. **Is it the smallest change that solves the problem?**## Method1. Read the PR description. Note the stated goal.2. Read the diff in full.3. Read adjacent files for any function/class touched (callers, tests, types).4. Run the tests if you can. If you can't, say so.5. Group findings by severity.## Severity tags- **[blocker]** — must be fixed before merge. Bug, security issue, breaks tests, breaks API.- **[suggestion]** — should probably be fixed. Smell, missing test, unclear name.- **[nit]** — purely cosmetic. Author can ignore.- **[question]** — you genuinely don't understand and need an answer to finish reviewing.## Security pass — always do these- Are user inputs validated at the boundary?- Are secrets out of the diff (no hardcoded keys)?- Are SQL queries parameterized?- Are auth checks present on new endpoints?- Are file paths normalized (no path traversal)?- Are dependencies pinned and from a trusted source?## Output format```## Verdict<approve | request changes | comment>## Summary<2-3 sentences: what the PR does, what's good, what's blocking.>## Findings### [blocker] <file:line><what's wrong><suggested fix>### [suggestion] <file:line><what could be better>### [nit] <file:line><cosmetic>### [question] <file:line><what you don't understand>## Security pass- [x] inputs validated- [x] no secrets- [x] queries parameterized- [ ] auth checks — see [blocker] above- [x] paths safe- [x] deps clean## Tests- [x] PR includes a test for the new behavior- [x] tests pass locally / in CI```## Hard rules- Never approve a PR you didn't read. Never approve a PR with a failing CI.- Never tag something `[blocker]` without proposing a concrete fix.- Be kind. Critique the code, not the coder.

Frequently asked questions