Code Reviewer
Run a structured pull-request and diff review with security, quality, and test coverage feedback before you merge.
Overview
Code Reviewer is an agent skill most often used in Ship (also Build) that performs comprehensive PR and path reviews with OWASP-aware security checks and Critical-through-Low severity feedback.
Install
npx skills add https://github.com/charon-fan/agent-playbook --skill code-reviewerWhat is this skill?
- Seven review lenses: correctness, security, performance, code quality, testing, documentation, maintainability
- Four severity buckets: Critical, High, Medium, and Low for actionable merge decisions
- Security pass aligned with OWASP Top 10, secrets exposure, and injection risks
- Optional Python script `review_checklist.py` to generate a repeatable review checklist
- Natural-language triggers: review this PR, check my changes, or review a directory
- 7 review categories
- 4 severity levels from Critical to Low
Adoption & trust: 607 installs on skills.sh; 58 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to merge changes but lack a consistent way to catch security, logic, and test gaps across the whole diff.
Who is it for?
Solo builders who want agent-driven PR reviews with explicit severity tiers before shipping to production.
Skip if: Teams that already enforce identical review rubrics in dedicated human-only tools and do not want agent commentary on every change.
When should I use this skill?
You say review this PR, check my changes, or review code under a path like src/auth/.
What do I get? / Deliverables
You get a structured review across seven categories with prioritized fixes so Critical and High issues are addressed before merge.
- Structured review report by category
- Severity-ranked action items (Critical, High, Medium, Low)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Merge-gate review is the canonical ship moment, even when you re-run the same skill on in-progress branches during build. The skill is invoked explicitly for PR review, path reviews, and pre-merge change checks—core ship/review workflows.
Where it fits
Review auth middleware on a feature branch before opening the PR.
Run a full PR review with Critical/High blockers listed before merge.
Double-check injection and secrets handling called out in the security category.
Sanity-check UI state and error handling in a large React diff.
How it compares
Use as a procedural review checklist inside the agent, not as a hosted code-review SaaS or static analyzer replacement.
Common Questions / FAQ
Who is code-reviewer for?
Indie and solo developers using Claude Code, Cursor, or similar agents who want standardized feedback on pull requests and local changes without hiring a full review board.
When should I use code-reviewer?
Use it in Ship before merging a PR, during Build when iterating on a feature branch, and anytime you ask the agent to review a folder or recent diff for security and test gaps.
Is code-reviewer safe to install?
It is read-oriented review guidance; check the Security Audits panel on this Prism page and avoid pasting live secrets into review prompts.
SKILL.md
READMESKILL.md - Code Reviewer
# Code Reviewer > A Claude Code skill for comprehensive code review of pull requests and code changes. ## Installation This skill is part of the [agent-playbook](../../README.md) collection. ## Usage When reviewing code, simply ask: ``` You: Review this PR You: Check my changes You: Review the code in src/auth/ ``` The skill will: 1. Analyze the changes 2. Check against security best practices 3. Evaluate code quality 4. Review test coverage 5. Provide structured feedback ## Review Categories | Category | Description | |----------|-------------| | **Correctness** | Logic, edge cases, error handling | | **Security** | OWASP Top 10, secrets, injection prevention | | **Performance** | N+1 queries, caching, algorithms | | **Code Quality** | DRY, KISS, naming, abstractions | | **Testing** | Coverage, edge cases, meaningful assertions | | **Documentation** | Comments, API docs, README | | **Maintainability** | Modularity, separation of concerns | ## Output Format Reviews are structured with severity levels: - **Critical**: Must fix before merge - **High**: Should fix before merge - **Medium**: Consider fixing - **Low**: Nice to have improvements ## Scripts Generate a review checklist: ```bash python scripts/review_checklist.py ``` ## References - [OWASP Top 10](https://owasp.org/www-project-top-ten/) - [Google Engineering Practices](https://google.github.io/eng-practices/review/) - [Clean Code](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) --- name: code-reviewer description: Reviews pull requests and code changes for quality, security, and best practices. Use when user asks for code review, PR review, or mentions reviewing changes. allowed-tools: Read, Grep, Glob, Bash, WebFetch, WebSearch metadata: hooks: after_complete: - trigger: self-improving-agent mode: background reason: "Learn from review patterns" - trigger: session-logger mode: auto reason: "Log review activity" --- # Code Reviewer A comprehensive code review skill that analyzes pull requests and code changes for quality, security, maintainability, and best practices. ## When This Skill Activates This skill activates when you: - Ask for a code review - Request a PR review - Mention reviewing changes - Say "review this" or "check this code" ## Review Process ### Phase 1: Context Gathering 1. **Get changed files** ```bash git diff main...HEAD --name-only git log main...HEAD --oneline ``` 2. **Get the diff** ```bash git diff main...HEAD ``` 3. **Understand project context** - Read relevant documentation - Check existing patterns in similar files - Identify project-specific conventions ### Phase 2: Analysis Categories #### 1. Correctness - [ ] Logic is sound and matches requirements - [ ] Edge cases are handled - [ ] Error handling is appropriate - [ ] No obvious bugs or typos #### 2. Security - [ ] No hardcoded secrets or credentials - [ ] Input validation and sanitization - [ ] SQL injection prevention - [ ] XSS prevention (for frontend) - [ ] Authentication/authorization checks - [ ] Safe handling of user data #### 3. Performance - [ ] No N+1 queries - [ ] Appropriate caching - [ ] Efficient algorithms - [ ] No unnecessary computations - [ ] Memory efficiency #### 4. Code Quality - [ ] Follows DRY principle - [ ] Follows KISS principle - [ ] Appropriate abstractions - [ ] Clear naming conventions - [ ] Proper typing (if TypeScript) - [ ] No commented-out code #### 5. Testing - [ ] Tests cover new functionality - [ ] Tests cover edge cases - [ ] Test assertions are meaningful - [ ] No brittle tests #### 6. Documentation - [ ] Complex logic is explained - [ ] Public APIs have documentation - [ ] JSDoc/TSDoc for functions - [ ] README updated if needed #### 7. Maintainability - [ ] Code is readable - [ ] Consistent style - [ ] Modular design - [ ] Separation of concerns ### Phase 3: Output Format Use this structured format fo