How do I install the Requesting Code Review skill?

Run npx skillmds add yanacuti1121/requesting-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 Requesting Code Review safe to use?

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

Which AI agents work with Requesting 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 Requesting Code Review free to use?

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

Who published Requesting Code Review?

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

Requesting Code Review by yanacuti1121

Name: Requesting Code Review
Rating: 4.2 (5 reviews)
Author: yanacuti1121

Requesting Code Review

Use when asked to review code, a diff, or a PR. Triggers on: 'review this', 'check my diff', 'review the PR', 'is this code ok', 'look at my changes', 'code review'. Focuses on real bugs, security issues, and env leaks — not style.

yanacuti1121 bfad43b 2.5 KB Updated Sep 9, 2026 2 repo stars

File contents

Requesting Code Review Skill

Code review has one job: find things that will break in production or compromise security. Style, preference, and micro-optimisations are out of scope unless the reviewer asked for them.

When to use this skill

User shares a diff, PR link, or file and asks for review
User says "review this", "check my changes", "is this safe"
User is about to merge and wants a second opinion

What to review

Priority 1 — Must catch

Logic bugs: off-by-one, wrong condition, silent failure path
Security issues: SQL injection, command injection, XSS, hardcoded secrets, open redirects
Env leaks: .env values, tokens, or credentials committed or logged
Data loss risk: missing transaction, unguarded DELETE/DROP, migration with no rollback

Priority 2 — Should catch

Missing error handling at system boundaries (external API calls, file I/O, DB queries)
Race conditions or non-atomic operations on shared state
Resource leaks: unclosed connections, missing finally blocks
Auth bypasses: missing permission check on a new route/endpoint

Priority 3 — Note if obvious

Dead code, console.log left in, commented-out blocks
Naming that will confuse the next reader

What NOT to review

Formatting/indentation (that's a linter's job)
Personal style preferences
Architecture opinions unless the user asks
Hypothetical future concerns ("what if we need to scale this")

Review format

## Code Review

**Reviewed:** [filename or PR#]

### Must fix
- [file:line] [issue] — [why it matters]

### Should fix
- [file:line] [issue]

### Notes
- [file:line] [minor observation]

### Verdict
APPROVE / REQUEST CHANGES / NEEDS DISCUSSION
Reason: [one sentence]

If there are no issues, say so explicitly: "No issues found in priority 1-2 categories."

How to run the review

# See the full diff first
git diff main...HEAD

# Check for secrets
git diff main...HEAD | grep -iE '(password|secret|token|api_key)\s*='

# Check for debug artifacts
git diff main...HEAD | grep -iE '(console\.log|print\(|debugger|TODO|FIXME)'

Show evidence for each finding — do not assert without pointing to the specific line.

---name: requesting-code-reviewdescription: Use when asked to review code, a diff, or a PR. Triggers on: 'review this', 'check my diff', 'review the PR', 'is this code ok', 'look at my changes', 'code review'. Focuses on real bugs, security issues, and env leaks — not style.--- # Requesting Code Review Skill Code review has one job: find things that will break in production or compromise security. Style, preference, and micro-optimisations are out of scope unless the reviewer asked for them. ## When to use this skill - User shares a diff, PR link, or file and asks for review - User says "review this", "check my changes", "is this safe" - User is about to merge and wants a second opinion ## What to review ### Priority 1 — Must catch - **Logic bugs**: off-by-one, wrong condition, silent failure path - **Security issues**: SQL injection, command injection, XSS, hardcoded secrets, open redirects - **Env leaks**: `.env` values, tokens, or credentials committed or logged - **Data loss risk**: missing transaction, unguarded `DELETE`/`DROP`, migration with no rollback ### Priority 2 — Should catch - **Missing error handling** at system boundaries (external API calls, file I/O, DB queries) - **Race conditions** or non-atomic operations on shared state - **Resource leaks**: unclosed connections, missing `finally` blocks - **Auth bypasses**: missing permission check on a new route/endpoint ### Priority 3 — Note if obvious - Dead code, console.log left in, commented-out blocks - Naming that will confuse the next reader ## What NOT to review - Formatting/indentation (that's a linter's job) - Personal style preferences - Architecture opinions unless the user asks - Hypothetical future concerns ("what if we need to scale this") ## Review format ```markdown ## Code Review **Reviewed:** [filename or PR#] ### Must fix - [file:line] [issue] — [why it matters] ### Should fix - [file:line] [issue] ### Notes - [file:line] [minor observation] ### Verdict APPROVE / REQUEST CHANGES / NEEDS DISCUSSION Reason: [one sentence] ``` If there are no issues, say so explicitly: "No issues found in priority 1-2 categories." ## How to run the review ```bash # See the full diff first git diff main...HEAD # Check for secrets git diff main...HEAD | grep -iE '(password|secret|token|api_key)\s*=' # Check for debug artifacts git diff main...HEAD | grep -iE '(console\.log|print\(|debugger|TODO|FIXME)' ``` Show evidence for each finding — do not assert without pointing to the specific line.

Frequently asked questions