Code Review
Run a structured pre-merge review on a PR URL, diff, or file path for security, performance, correctness, and maintainability before you merge solo-shipped code.
Overview
Code Review is an agent skill most often used in Ship (also Build → backend/integrations) that reviews diffs and PRs for security, performance, correctness, and maintainability before you merge.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill code-reviewWhat is this skill?
- Standalone review from pasted diff, PR URL, or file paths—no plugin graph required
- Security lens aligned with OWASP top 10, injection, and auth issues
- Performance checks for N+1 queries, memory leaks, and complexity hotspots
- Correctness pass for edge cases, error handling gaps, and race conditions
- Style and maintainability notes with concrete code-example suggestions
- 4 review lenses: security, performance, correctness, style
- OWASP top 10 oriented security audit
Adoption & trust: 5.4k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to merge a change but do not have time to manually hunt for injection risks, N+1 queries, missing edge cases, and sloppy error handling in every file.
Who is it for?
Solo builders merging agent-generated or fast-moving PRs who want OWASP- and performance-aware feedback without hiring a full-time reviewer.
Skip if: Teams that already enforce mandatory human review sign-off on every change and only want style linting with zero security narrative.
When should I use this skill?
PR URL or diff, "review this before I merge", "is this code safe?", or when checking N+1, injection, edge cases, or error handling.
What do I get? / Deliverables
You get a structured review with prioritized findings and example fixes so you can patch gaps before merge instead of discovering them in production.
- Structured findings by security, performance, correctness, and style
- Actionable suggestions with code examples
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because triggers explicitly target pre-merge checks (“review this before I merge”, “is this code safe?”), which is the gate between finishing a change and releasing it. Review subphase matches the skill’s core job: actionable feedback on diffs rather than writing tests or deploying.
Where it fits
Paste a GitHub PR URL and ask for injection and auth issues before you merge a solo SaaS hotfix.
Point at webhook handler files to catch race conditions and error-handling gaps before wiring production callbacks.
Run an OWASP-oriented pass on a diff that adds new user-input paths right before release week.
How it compares
Use instead of asking the agent to “quickly skim” a PR—this skill names explicit lenses (security, N+1, edge cases) rather than generic praise.
Common Questions / FAQ
Who is code-review for?
Indie and solo developers shipping with Claude Code, Cursor, or Codex who own merge decisions and need a repeatable pre-merge audit on diffs and PRs.
When should I use code-review?
In Ship → review before merging; also late Build when finishing API or integration changes—trigger with a PR URL, diff, or “review this before I merge” / “is this code safe?”.
Is code-review safe to install?
It reviews code you point at and does not require special permissions by itself; check the Security Audits panel on this Prism page before installing any plugin bundle.
SKILL.md
READMESKILL.md - Code Review
# /code-review > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Review code changes with a structured lens on security, performance, correctness, and maintainability. ## Usage ``` /code-review <PR URL or file path> ``` Review the provided code changes: @$1 If no specific file or URL is provided, ask what to review. ## How It Works ``` ┌─────────────────────────────────────────────────────────────────┐ │ CODE REVIEW │ ├─────────────────────────────────────────────────────────────────┤ │ STANDALONE (always works) │ │ ✓ Paste a diff, PR URL, or point to files │ │ ✓ Security audit (OWASP top 10, injection, auth) │ │ ✓ Performance review (N+1, memory leaks, complexity) │ │ ✓ Correctness (edge cases, error handling, race conditions) │ │ ✓ Style (naming, structure, readability) │ │ ✓ Actionable suggestions with code examples │ ├─────────────────────────────────────────────────────────────────┤ │ SUPERCHARGED (when you connect your tools) │ │ + Source control: Pull PR diff automatically │ │ + Project tracker: Link findings to tickets │ │ + Knowledge base: Check against team coding standards │ └─────────────────────────────────────────────────────────────────┘ ``` ## Review Dimensions ### Security - SQL injection, XSS, CSRF - Authentication and authorization flaws - Secrets or credentials in code - Insecure deserialization - Path traversal - SSRF ### Performance - N+1 queries - Unnecessary memory allocations - Algorithmic complexity (O(n²) in hot paths) - Missing database indexes - Unbounded queries or loops - Resource leaks ### Correctness - Edge cases (empty input, null, overflow) - Race conditions and concurrency issues - Error handling and propagation - Off-by-one errors - Type safety ### Maintainability - Naming clarity - Single responsibility - Duplication - Test coverage - Documentation for non-obvious logic ## Output ```markdown ## Code Review: [PR title or file] ### Summary [1-2 sentence overview of the changes and overall quality] ### Critical Issues | # | File | Line | Issue | Severity | |---|------|------|-------|----------| | 1 | [file] | [line] | [description] | 🔴 Critical | ### Suggestions | # | File | Line | Suggestion | Category | |---|------|------|------------|----------| | 1 | [file] | [line] | [description] | Performance | ### What Looks Good - [Positive observations] ### Verdict [Approve / Request Changes / Needs Discussion] ``` ## If Connectors Available If **~~source control** is connected: - Pull the PR diff automatically from the URL - Check CI status and test results If **~~project tracker** is connected: - Link findings to related tickets - Verify the PR addresses the stated requirements If **~~knowledge base** is connected: - Check changes against team coding standards and style guides ## Tips 1. **Provide context** — "This is a hot path" or "This handles PII" helps me focus. 2. **Specify concerns** — "Focus on security" narrows the review. 3. **Include tests** — I'll check test coverage and quality too.