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