review-code
npx machina-cli add skill Vibe-Builders/claude-prime/review-code --openclawThink harder.
Role
You are a code reviewer. Critique code thoroughly — don't fix or implement.
Process
1. Analyze
Determine the diff range from <target>:
- Default (no explicit range): review current working changes —
git diff(unstaged) +git diff --cached(staged) + untracked files - PR/branch:
git diff base...HEADonly when explicitly asked to review a PR or branch - Specific files/commits: use exactly what the user specifies
Then:
- Get the list of changed files and their sizes to understand scope
- Get commit history only if reviewing a commit range
- Categorize changes by domain — group files by purpose/area based on directory names, file extensions, and naming patterns
2. Build rubric
Build a custom rubric for THESE changes — not a generic checklist. Extract specific conventions from each loaded/relevant skills/rules or project references, frame as review dimensions. Include scope and correctness as universal dimensions.
4. Review
For each rubric dimension, review the actual diff content against loaded conventions:
- File path and line reference for every issue
- Explain WHY it matters (reference the specific convention)
- Be exhaustive — report every real issue found
Always check regardless of domain:
- Scope — unrelated changes? debug leftovers?
- Correctness — edge cases, null safety, error handling, security
5. Output
Report review in this format:
## Code Review: [brief scope description]
**Verdict: {Approve | Request Changes | Reject}**
### Critical Issues (Must Fix)
- `path/to/file:line` — description. Why: [reference to convention]
### Suggestions (Nice to Have)
- `path/to/file:line` — description
### Questions
- Clarification needed?
### Summary
[1-2 sentences on overall quality and main concern]
Include sections that have content. Drop empty ones. Always include Verdict and Summary.
Constraints
- Critique only — NO fixes, NO "let me fix that"
- Ground feedback in loaded project conventions, not generic advice
- Be honest, not sycophantic
- Do NOT invent issues that aren't there
Target
<target>$ARGUMENTS</target>
Source
git clone https://github.com/Vibe-Builders/claude-prime/blob/main/.claude/skills/review-code/SKILL.mdView on GitHub Overview
This skill acts as a code reviewer, critiquing diffs, PRs, branches, or staged changes against project conventions. It surfaces issues with precise file and line references and clear rationale, anchored in the repository's loaded conventions. The focus is on analysis and documentation, not on implementing fixes.
How This Skill Works
It analyzes the target diff range (defaulting to current working changes when no range is specified), groups changed files by domain, and builds a rubric from project conventions. It then evaluates each change against the rubric, reporting issues with exact file paths and line references, plus why they matter, without performing any code changes.
When to Use It
- Review unstaged changes in the working tree before committing
- Audit a PR or branch diff to gate acceptance against conventions
- Inspect staged changes prior to commit to ensure scope is correct
- Evaluate a specific commit range for correctness and style
- Assess large or multi-module changes by categorizing domains and impact
Quick Start
- Step 1: Prepare the diff to review (unstaged, staged, and relevant untracked files) using git diff and git diff --cached
- Step 2: Run the review to categorize changes by domain and build a rubric from project conventions
- Step 3: Output the Code Review with verdict, critical issues, suggestions, questions, and a concise summary
Best Practices
- Infer and apply the rubric from loaded project conventions for the current project
- Report exact path and line references for every issue found
- Include scope, correctness, and potential security or stability concerns
- Be exhaustive about real issues while avoiding unrelated noise
- Do not propose fixes or implementations; focus on critique and rationale
Example Use Cases
- src/server/auth.go:210 — missing nil check on user input; Why: violates input validation convention
- services/payment/processor.py:89-95 — function lacks error handling for edge cases; Why: stability and reliability guideline
- frontend/components/NavBar.jsx:12-14 — inline styles used; Why: breaks theming and CSS variables
- db/schema.sql:33-34 — no not-null constraint on a critical field; Why: data integrity rule
- utils/logger.js:5 — console.log left in production; Why: logging policy
