Review Code Skill for Claude
Review code for quality, correctness, and fit. Use when the user wants judgment on code that already exists — their own changes, a teammate's patch, a PR, branch, commit, diff, staged changes, or one or more files to look over. Activate on requests like review, look over, sanity check, critique, code review, or 'is this good?' The key signal is that the user wants evaluation of existing code and its tradeoffs, not implementation, debugging, or explanation. This skill works independently, but when plans, specs, task artifacts, or prior discussion exist, use them to understand why the code exists before judging it.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/avibebuilder/claude-prime --skill review-codeWhat comes with it
3 482 bytes besides the instructionThe instruction itself
8 sections, as written by the authorultrathink
Process
Critique only — no fixes or implementation. Understand *why* the code exists before judging it.
1. Identify the review target
Prefer in order: explicit <target>, changes made in this conversation, working diff. If unclear, ask.
Then gather enough context (PR/issue text, plans, surrounding code) to avoid misreads. Don't turn every review into archaeology — if a missing detail would materially change judgment, ask briefly.
2. Match depth to risk
- Quick — small, local, low-risk; keep output brief
- Standard — normal feature or refactor
- Deep — risky, cross-cutting, security-sensitive, or surprising
3. Review flow first, then details
Understand how important parts work before commenting line by line. Focus on load-bearing logic, edge cases, scope drift, and intentional tradeoffs.
4. Report
For each finding: file path + line, why it matters, severity.
- Critical — correctness, safety, broken edge cases, scope violations. Requires evidence in the code — speculative failure modes belong in Questions.
- Suggestion — non-blocking improvements
- Question — missing context or unconfirmable concerns
If something looks odd but context supports it, acknowledge rather than flag.
5. Output format
## Code Review: [scope]
**Verdict: {Approve | Request Changes | Reject}**
### Inferred Intent
[Only when context supports it]
### Critical Issues (Must Fix)
- `path/to/file:line` — concise description. Why: [reason]
### Suggestions (Nice to Have)
- `path/to/file:line` — concise description
### Questions
- [Clarifications on intent or tradeoffs]
### Summary
[1-2 sentences]
Include only sections with content. Always include Verdict and Summary.
Boundaries
- Read surrounding code when the diff alone is misleading.
- Deliberate decisions (inline comments, user-stated tradeoffs) are not defects — raise as Question only with concrete evidence.
- Don't judge by personal preference when project fit explains the choice.
- Name the right approach ("needs parameterized queries") but don't write corrected code.
Target
<target>$ARGUMENTS</target>
Other skills for the same job
different authors, same section of the catalogue
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
Comprehensive GitHub code review with AI-powered swarm coordination
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL). It focuses on correctness, maintainability, and adherence to project standards.
Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.
How to use it
Take avibebuilder/review-code from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.