Code review
Review a GitHub Pull Request for bugs, security, performance, and code quality. Use when user asks to review a PR or wants pull request feedback. Don't use for reviewing local uncommitted changes, creating new PRs, or merging branches.From its SKILL.md
npx -y skills add helderberto/agent-skills --skill code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
- runs commandsInstructs the agent to run 1 command, including `gh auth status`.
SKILL.md
2.7 KB, 567 tokens by cl100k_base, as published. Nobody here has run it
Review Pull Request
Mode: $ARGUMENTS
If mode is one of the following, adjust the review:
- BUGS: Focus only on logical or other bugs
- SECURITY: Focus only on security issues
- PERFORMANCE: Focus only on performance issues
Workflow
- Analyze the diff and pre-loaded PR context
- Read changed files to understand full context
- Review based on mode (or all categories if no mode set)
- Provide structured feedback
Review criteria
Apply all axes (or narrow to the mode above):
- Correctness: Logic bugs, off-by-ones, race conditions, unhandled states, missing error paths
- Readability: Functions <50 lines, nesting <3 levels, no dead code/unused imports
- Security: No exposed secrets, no
any, no unvalidated external data - Immutability: No push/pop/splice/direct mutation
- Patterns: Consistent with codebase conventions, no reinvented wheels
- Performance: Unnecessary re-renders, O(n²) where O(n) works, missing memoization
- Code smells: Duplicated code, parameters >3 without options object, magic numbers
Output format
Group by severity:
- Critical - must fix before merge (bugs, security vulnerabilities)
- Suggestions - improvements worth considering
- Positives - good patterns to call out
Use file:line references for all findings. Include suggested fix for each critical issue.
Rules
- Review ALL changed files, not just the latest commit
- Be specific, skip nitpicks
Common Rationalizations
| Excuse | Rebuttal |
|---|---|
| "Too small to review" | Small changes cause big bugs — review everything |
| "It's just a refactor" | Refactors break behavior silently — verify contracts preserved |
| "Tests pass so it's fine" | Tests don't catch readability, security, or design issues |
| "I'll clean it up later" | Later never comes — fix now or it ships as-is |
Verification
- Every changed file reviewed (not just the diff summary)
- No critical issue left without a suggested fix
- Security concerns flagged with specific fix
- Feedback grouped by severity, not file order
Error Handling
- If
gh pr viewfails → rungh auth statusto verify authentication; ask user for PR number if not on a PR branch - If a changed file is deleted in the PR → skip reading it; note it was removed
- If diff is too large → prioritize changed files with highest risk (auth, payments, data mutation)
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most code review skills give in 567 tokens
Counted across 668 of the 814 authors here whose files we hold, read 2026-09-06
- Provide technical reasoning when pushing backin 84 of 668, across 70 files
- Fix critical issues immediatelyin 77 of 668, across 60 files
- Dispatch a code reviewer subagentin 76 of 668, across 59 files
- Fix important issues before proceedingin 73 of 668, across 56 files
- Ask for clarification on unclear itemsin 68 of 668, across 56 files
- Verify feedback against codebase before implementationin 66 of 668, across 55 files
- Implement fixes one at a timein 64 of 668, across 53 files
- Test each fix individuallyin 62 of 668, across 51 files
- Restate technical requirements in own wordsin 57 of 668, across 46 files
- Reply to inline comments in the specific threadin 51 of 668, across 40 files
- Note minor issues for laterin 49 of 668, across 34 files
- Group findings by severityin 48 of 668, across 47 files
Said here and by no other author read
- Analyze the diff and full PR context
- Group feedback by severity
- Ask author to split PRs over 1000 lines
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.