When to Use This Skill
| Use this skill when... |
Use something else instead when... |
| Running an end-to-end review across quality, security, perf, and tests |
Walking a manual security/correctness checklist → code-review-checklist |
| Auditing a directory or PR delta with delegated agent analysis |
Specifically scanning for code smells → code-antipatterns |
| Spotting missing test cases or weak assertions |
Auditing test code quality on its own → code-test-quality |
| Producing a consolidated review report |
Refactoring after the review surfaces issues → code-refactor |
Context
- Review path:
$1 (defaults to current directory if not specified)
Parameters
$1: Path to review (defaults to current directory)
Your task
Delegate this task to the agents-plugin:review agent.
Use the Agent tool with subagent_type: agents-plugin:review to perform a comprehensive code review.
First, use the Glob tool to discover source files to review:
**/*.py, **/*.js, **/*.ts, **/*.go, **/*.rs for source files
**/*test* patterns for test files
Then pass the discovered files to the agent.
The code-review agent should:
Analyze code quality:
- Naming conventions and readability
- Code structure and maintainability
- SOLID principles adherence
Security assessment:
- Input validation vulnerabilities
- Authentication and authorization issues
- Secrets and sensitive data exposure
Performance evaluation:
- Bottlenecks and inefficiencies
- Memory usage patterns
- Optimization opportunities
Architecture review:
- Design patterns usage
- Component coupling
- Dependency management
Test coverage gaps:
- Missing test cases
- Edge cases not covered
- Integration test needs
Apply fixes where appropriate and safe
Re-verify each candidate finding (false-positive gate — run BEFORE reporting):
For every candidate finding from steps 1–5, re-read the cited code at the
reported file:line and confirm the claim actually holds against the current
source — not against a remembered or assumed shape. A finding survives only if
the re-read confirms it; drop the rest. See "Re-verification Pass" below.
Score every surviving finding against the anchors below:
- Assign a severity (Critical/High/Medium/Low) using the "Severity Rubric".
- Assign a confidence (High/Medium/Low) using the "Confidence Scale", and
drop or explicitly flag findings below the reporting threshold.
Generate report with:
- Surviving findings ranked most-severe first, each carrying its
severity, confidence, and verified file:line
- Summary of issues found/fixed
- Remaining manual interventions needed
- Improvement recommendations
Provide the agent with:
- The review path from context
- Project type (language/framework)
- Any specific focus areas requested
The agent has expertise in:
- Multi-language code analysis (Python, TypeScript, Go, Rust)
- LSP integration for accurate diagnostics
- Security vulnerability patterns (OWASP)
- Performance analysis and optimization
Severity Rubric
Score every surviving finding against these anchors. Rank the report
most-severe first.
| Severity |
Criteria |
| Critical |
Exploitable security hole, data loss/corruption, or a crash on a common path. Ship-blocker — must fix before merge. |
| High |
A real correctness bug that misbehaves on realistic input, a serious perf regression (N+1, unbounded growth), or an auth/validation gap without a known exploit. Fix before merge. |
| Medium |
Bug on an edge case, missing error handling, a test gap over important behavior, or a maintainability problem that will bite soon. Fix or file a follow-up. |
| Low |
Style, naming, minor readability, or a nit with no behavioral impact. Optional. |
Confidence Scale
Assign each finding a confidence and let it gate what reaches the report. A
finding whose defect you cannot demonstrate from the code in front of you is a
guess, and guesses erode trust in the review.
| Confidence |
Meaning |
Reporting rule |
| High |
The defect is provable from the cited code — you can name the input and the wrong result. |
Report. |
| Medium |
The defect is likely but depends on context you could not fully see. |
Report, labeled as needing confirmation. |
| Low |
Speculative — a hunch not grounded in the code as read. |
Drop, or downgrade to a one-line "consider checking X" note; never present as a defect. |
The reporting threshold is Medium: report High and Medium findings; do not
present Low-confidence hunches as findings.
Re-verification Pass
Before the report step, re-check every candidate finding against the actual
code. This kills false positives mechanically rather than trusting the initial
read:
- Re-open the finding's
file:line with Read and confirm the cited code
still says what the finding claims (line numbers drift; assumptions decay).
- Confirm the failure the finding describes is reachable — name the concrete
input or state that triggers it. If you cannot, it is Low confidence.
- Keep only findings that survive both checks. Every reported finding must
carry a verified
file:line, a severity, and a confidence.
Agent Teams (Optional)
For comprehensive review of large codebases, spawn specialized review teammates in parallel:
| Teammate |
Focus |
Value |
| Security reviewer |
OWASP, secrets, auth flaws |
Deep security analysis without blocking quality review |
| Performance reviewer |
N+1 queries, algorithmic complexity, resource leaks |
Performance-focused review in parallel |
| Correctness reviewer |
Logic errors, edge cases, type safety |
Functional correctness in parallel |
This is optional — the skill works without agent teams for standard reviews.
Related Configure Skills
- If security scanning not configured →
/configure:security
- If linting not set up →
/configure:linting
- If test coverage not tracked →
/configure:coverage
1---
2created: 2025-12-16
3modified: 2026-07-04
4reviewed: 2026-07-04
5allowed-tools: Task, TodoWrite, Glob, Read
6model: opus
7description: Code review for quality, security, performance, and architecture. Use when reviewing code, auditing OWASP, checking SOLID, or finding perf bottlenecks and test gaps.
8args: "[PATH]"
9argument-hint: "[PATH]"
10name: code-review
11agent: general-purpose
12context: fork
13---
14
15## When to Use This Skill
16
17| Use this skill when... | Use something else instead when... |
18|------------------------|------------------------------------|
19| Running an end-to-end review across quality, security, perf, and tests | Walking a manual security/correctness checklist → `code-review-checklist` |
20| Auditing a directory or PR delta with delegated agent analysis | Specifically scanning for code smells → `code-antipatterns` |
21| Spotting missing test cases or weak assertions | Auditing test code quality on its own → `code-test-quality` |
22| Producing a consolidated review report | Refactoring after the review surfaces issues → `code-refactor` |
23
24## Context
25
26- Review path: `$1` (defaults to current directory if not specified)
27
28## Parameters
29
30- `$1`: Path to review (defaults to current directory)
31
32## Your task
33
34**Delegate this task to the `agents-plugin:review` agent.**
35
36Use the Agent tool with `subagent_type: agents-plugin:review` to perform a comprehensive code review.
37
38First, use the Glob tool to discover source files to review:
39- `**/*.py`, `**/*.js`, `**/*.ts`, `**/*.go`, `**/*.rs` for source files
40- `**/*test*` patterns for test files
41Then pass the discovered files to the agent.
42
43The code-review agent should:
44
451. **Analyze code quality**:
46 - Naming conventions and readability
47 - Code structure and maintainability
48 - SOLID principles adherence
49
502. **Security assessment**:
51 - Input validation vulnerabilities
52 - Authentication and authorization issues
53 - Secrets and sensitive data exposure
54
553. **Performance evaluation**:
56 - Bottlenecks and inefficiencies
57 - Memory usage patterns
58 - Optimization opportunities
59
604. **Architecture review**:
61 - Design patterns usage
62 - Component coupling
63 - Dependency management
64
655. **Test coverage gaps**:
66 - Missing test cases
67 - Edge cases not covered
68 - Integration test needs
69
706. **Apply fixes** where appropriate and safe
71
727. **Re-verify each candidate finding** (false-positive gate — run BEFORE reporting):
73 For every candidate finding from steps 1–5, re-read the cited code at the
74 reported `file:line` and confirm the claim actually holds against the current
75 source — not against a remembered or assumed shape. A finding survives only if
76 the re-read confirms it; drop the rest. See "Re-verification Pass" below.
77
788. **Score every surviving finding** against the anchors below:
79 - Assign a **severity** (Critical/High/Medium/Low) using the "Severity Rubric".
80 - Assign a **confidence** (High/Medium/Low) using the "Confidence Scale", and
81 drop or explicitly flag findings below the reporting threshold.
82
839. **Generate report** with:
84 - Surviving findings ranked most-severe first, each carrying its
85 `severity`, `confidence`, and verified `file:line`
86 - Summary of issues found/fixed
87 - Remaining manual interventions needed
88 - Improvement recommendations
89
90Provide the agent with:
91- The review path from context
92- Project type (language/framework)
93- Any specific focus areas requested
94
95The agent has expertise in:
96- Multi-language code analysis (Python, TypeScript, Go, Rust)
97- LSP integration for accurate diagnostics
98- Security vulnerability patterns (OWASP)
99- Performance analysis and optimization
100
101## Severity Rubric
102
103Score every surviving finding against these anchors. Rank the report
104most-severe first.
105
106| Severity | Criteria |
107|----------|----------|
108| **Critical** | Exploitable security hole, data loss/corruption, or a crash on a common path. Ship-blocker — must fix before merge. |
109| **High** | A real correctness bug that misbehaves on realistic input, a serious perf regression (N+1, unbounded growth), or an auth/validation gap without a known exploit. Fix before merge. |
110| **Medium** | Bug on an edge case, missing error handling, a test gap over important behavior, or a maintainability problem that will bite soon. Fix or file a follow-up. |
111| **Low** | Style, naming, minor readability, or a nit with no behavioral impact. Optional. |
112
113## Confidence Scale
114
115Assign each finding a confidence and let it gate what reaches the report. A
116finding whose defect you cannot demonstrate from the code in front of you is a
117guess, and guesses erode trust in the review.
118
119| Confidence | Meaning | Reporting rule |
120|------------|---------|----------------|
121| **High** | The defect is provable from the cited code — you can name the input and the wrong result. | Report. |
122| **Medium** | The defect is likely but depends on context you could not fully see. | Report, labeled as needing confirmation. |
123| **Low** | Speculative — a hunch not grounded in the code as read. | Drop, or downgrade to a one-line "consider checking X" note; never present as a defect. |
124
125The reporting threshold is **Medium**: report High and Medium findings; do not
126present Low-confidence hunches as findings.
127
128## Re-verification Pass
129
130Before the report step, re-check every candidate finding against the actual
131code. This kills false positives mechanically rather than trusting the initial
132read:
133
1341. Re-open the finding's `file:line` with `Read` and confirm the cited code
135 still says what the finding claims (line numbers drift; assumptions decay).
1362. Confirm the failure the finding describes is reachable — name the concrete
137 input or state that triggers it. If you cannot, it is Low confidence.
1383. Keep only findings that survive both checks. Every reported finding must
139 carry a verified `file:line`, a severity, and a confidence.
140
141## Agent Teams (Optional)
142
143For comprehensive review of large codebases, spawn specialized review teammates in parallel:
144
145| Teammate | Focus | Value |
146|----------|-------|-------|
147| Security reviewer | OWASP, secrets, auth flaws | Deep security analysis without blocking quality review |
148| Performance reviewer | N+1 queries, algorithmic complexity, resource leaks | Performance-focused review in parallel |
149| Correctness reviewer | Logic errors, edge cases, type safety | Functional correctness in parallel |
150
151This is optional — the skill works without agent teams for standard reviews.
152
153## Related Configure Skills
154
155- If security scanning not configured → `/configure:security`
156- If linting not set up → `/configure:linting`
157- If test coverage not tracked → `/configure:coverage`