| name | code-review |
| description | AI code review for PR or local changes |
Code Review
Comprehensive AI-powered code review for PRs and local changes — enterprise-grade alternative to CodeRabbit
When to use
- "code review"
- "review my PR"
- "review PR #123"
- "check my changes"
- "what's wrong with my code"
- "security review"
- "full review"
- "/review"
- "/review-pr"
Dependencies
- External:
gh CLI (GitHub), git
Modes
1. Local review (uncommitted changes)
Reviews git diff — changes not yet committed.
2. Branch review (vs main/master)
Reviews all changes in current branch compared to main.
3. PR review (GitHub)
Fetches diff from GitHub PR and can post comments.
4. Focused review
User can request specific focus: security, performance, bugs, style, etc.
How to execute
Step 0: Check if review needed
Skip review if:
- PR is draft (
gh pr view --json isDraft)
- PR is already closed/merged
- Only documentation changes (.md, .txt, LICENSE)
- Only config changes (.json, .yaml, .toml) without code impact
- Trivial changes (<5 lines, whitespace only, version bumps)
Inform user and ask to confirm if they still want review.
Step 1: Determine mode
Ask user or detect automatically:
- If PR number provided → PR review
- If uncommitted changes exist → local review
- If on feature branch → branch review
- If specific focus requested → apply focus filter
Step 2: Get diff
Local:
git diff HEAD
Branch (vs main):
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main")
git diff $DEFAULT_BRANCH...HEAD
PR:
gh pr diff <PR_NUMBER>
Step 3: Get context
For thorough review, read related files:
git diff --name-only HEAD
Step 3b: Filter pre-existing issues
Before reporting an issue, check if it was introduced in this PR:
git blame -L <start>,<end> <file> --porcelain | head -1
Skip issues that:
- Existed before this PR (old blame hash)
- Are in unchanged lines
- Were introduced by a different author long ago
Only report issues introduced or modified in current changes.
This prevents noise from legacy code and focuses review on new changes.
Step 4: Comprehensive Analysis
Apply ALL relevant checks from the checklist below.
Step 5: Confidence Scoring
Rate each issue 0-100:
| Score | Confidence | When to use |
|---|
| 90-100 | Certain | Clear vulnerability (SQL injection with user input), obvious crash |
| 70-89 | High | Likely bug, security risk, definite code smell |
| 50-69 | Medium | Potential issue, needs context to confirm |
| 25-49 | Low | Style preference, minor suggestion |
| 0-24 | Skip | Probably false positive, pre-existing, or nitpick |
Only report issues with confidence ≥70.
Mark as false positive and skip:
- Pre-existing issues (caught by Step 3b)
- Issues that linters will catch (eslint, prettier)
- Pedantic nitpicks without real impact
- Code that looks wrong but has valid reason (check comments)
- Issues with explicit ignore comments (
// eslint-disable, # noqa)
Step 6: Output result
Format:
## Code Review Summary
**Reviewed:** X files, Y lines changed
**Risk Level:** Critical / High / Medium / Low
### Critical Issues (must fix)
- [file:line] Description — Why it matters
### High Priority
- [file:line] Description
### Medium Priority
- [file:line] Description
### Low Priority / Suggestions
- [file:line] Description
### Good Practices
- What was done well
For GitHub PR — post comments:
gh pr comment <PR_NUMBER> --body "## AI Code Review
[Review content]"
gh api repos/{owner}/{repo}/pulls/{pr}/comments \
--method POST \
-f body="Issue description and fix suggestion" \
-f path="src/file.ts" \
-f line=42 \
-f side="RIGHT"
COMPREHENSIVE REVIEW CHECKLIST
1. SECURITY (OWASP Top 10 + Extended)
1.1 Injection
1.2 Broken Authentication
1.3 Sensitive Data Exposure
1.4 XML External Entities (XXE)
1.5 Broken Access Control
1.6 Security Misconfiguration
1.7 Cross-Site Scripting (XSS)
1.8 Insecure Deserialization
1.9 Using Components with Known Vulnerabilities
1.10 Insufficient Logging & Monitoring
1.11 Additional Security Checks
2. BUGS & LOGIC ERRORS
2.1 Null/Undefined Handling
2.2 Type Issues
2.3 Async/Concurrency
2.4 Loop/Iteration Errors
2.5 Boundary/Edge Cases
2.6 State Management
2.7 Error Handling
2.8 Resource Management
2.9 Business Logic
3. PERFORMANCE
3.1 Database
3.2 API/Network
3.3 Frontend
3.4 Algorithms
3.5 Caching
4. CODE QUALITY
4.1 Readability
4.2 Maintainability
4.3 SOLID Principles
4.4 Error Messages
4.5 API Design
4.6 Configuration
5. TESTING
5.1 Test Coverage
5.2 Test Quality
5.3 Test Patterns
6. ACCESSIBILITY (a11y)
7. INTERNATIONALIZATION (i18n)
8. DOCUMENTATION
9. DEVOPS / INFRASTRUCTURE
10. GIT/VERSION CONTROL
LANGUAGE-SPECIFIC CHECKS (apply if relevant files detected)
11. REACT / NEXT.JS (if .tsx, .jsx files)
12. TYPESCRIPT (if .ts, .tsx files)
13. PYTHON (if .py files)
14. NODE.JS / EXPRESS (if package.json with express)
15. SQL / DATABASE (if .sql files or ORM usage)
Parameters
| Parameter | Description | Default |
|---|
PR_NUMBER | Pull Request number | - |
--post | Post comments to GitHub | false |
--severity | Minimum level (critical/high/medium/low) | low |
--focus | Focus area: security, performance, bugs, quality, testing, a11y, i18n, all | all |
Examples
Example 1: Full review
User: full code review
Claude: [git diff HEAD]
Claude: [comprehensive analysis using all checklists]
Claude:
## Code Review Summary
**Reviewed:** 5 files, 234 lines changed
**Risk Level:** High
### Critical Issues (2)
1. [src/api/auth.ts:45] SQL Injection - User input passed directly to query
2. [src/utils/crypto.ts:12] Weak cryptography - Using MD5 for password hashing
### High Priority (3)
1. [src/services/user.ts:78] Missing authorization check - IDOR vulnerability
2. [src/api/data.ts:23] N+1 query - 50 queries in loop
3. [src/components/Form.tsx:156] XSS - dangerouslySetInnerHTML with user content
### Medium Priority (5)
...
Example 2: Security-focused review
User: security review PR 123
Claude: [applies only security checklist]
Claude: Found 3 security issues...
Example 3: Performance review
User: check performance issues in my changes
Claude: [applies only performance checklist]
Claude: Found 2 performance issues...
Severity Levels
| Level | Description | Examples |
|---|
| Critical | Must fix before merge. Security vulnerabilities, data loss risks | SQL injection, hardcoded secrets, auth bypass |
| High | Should fix before merge. Significant bugs or security issues | N+1 queries, XSS, missing error handling |
| Medium | Fix soon. Code quality, minor bugs | DRY violations, missing tests, complexity |
| Low | Nice to have. Suggestions, style | Naming, comments, minor optimizations |
Troubleshooting
| Problem | Solution |
|---|
gh: command not found | brew install gh && gh auth login |
| No diff output | Check if changes exist: git status |
| PR not found | Check PR number and access rights |
| Can't post comments | Check permissions: gh auth status |
| Review too long | Use --focus to narrow scope |
| False positives | Mention specific context to skip |
Limitations
- Static analysis only — cannot run code
- Cannot see runtime behavior
- May miss complex cross-file issues
- Needs context for architectural decisions
- GitHub API rate limits when posting many comments
- Language-specific checks may vary in depth
If you're getting false positives
Step 1: Use severity filter
Most false positives are low/medium severity. Start with high-only:
"review PR 123 --severity=high"
"review my changes, only critical and high issues"
Step 2: Use focus filter
Narrow to specific categories you care about:
"security review PR 123"
"review PR 123 --focus=bugs,security"
"check only performance issues"
Step 3: Tell Claude to skip specific issues
In the same conversation, provide context:
"ignore the N+1 warning in admin routes - it's intentional, low traffic"
"skip any type warnings in src/legacy/ - that's legacy code"
"the raw SQL in migrations/ is fine, we use raw migrations"
Step 4: Add inline comment in code
For persistent false positives that keep appearing:
const query = `SELECT * FROM users WHERE id = ${sanitizedId}`;
CACHE = {}
Step 5: Report to improve the skill
If the same false positive keeps appearing across reviews:
- Open issue at github.com/your-org/claude-code-review-skill/issues
- Include:
- File and line number
- What was flagged
- Why it's a false positive
- Code snippet if possible
This helps improve the skill for everyone.
Default behavior
The skill is designed to minimize false positives out of the box:
- Baseline filtering — Only reports issues introduced in current PR/changes (via git blame)
- Confidence threshold — Only reports issues with ≥70% confidence
- Skips linter territory — Doesn't flag formatting, style issues that ESLint/Prettier catch
- Skips pre-existing issues — Won't complain about old code you didn't touch
- Skips trivial changes — Version bumps, whitespace, documentation-only changes