Code Review Expert
Overview
Perform a structured review of the current git changes with focus on SOLID, architecture, removal candidates, and security risks. Default to review-only output unless the user asks to implement changes.
Severity Levels
| Level |
Name |
Description |
Action |
| P0 |
Critical |
Security vulnerability, data loss risk, correctness bug |
Must block merge |
| P1 |
High |
Logic error, significant SOLID violation, performance regression |
Should fix before merge |
| P2 |
Medium |
Code smell, maintainability concern, minor SOLID violation |
Fix in this PR or create follow-up |
| P3 |
Low |
Style, naming, minor suggestion |
Optional improvement |
Workflow
1) Preflight context
- Use
git status -sb, git diff --stat, and git diff to scope changes.
- If needed, use
rg or grep to find related modules, usages, and contracts.
- Identify entry points, ownership boundaries, and critical paths (auth, payments, data writes, network).
Edge cases:
- No changes: If
git diff is empty, inform user and ask if they want to review staged changes or a specific commit range.
- Large diff (>500 lines): Summarize by file first, then review in batches by module/feature area.
- Mixed concerns: Group findings by logical feature, not just file order.
2) SOLID + architecture smells
- Load
references/solid-checklist.md for specific prompts.
- Look for:
- SRP: Overloaded modules with unrelated responsibilities.
- OCP: Frequent edits to add behavior instead of extension points.
- LSP: Subclasses that break expectations or require type checks.
- ISP: Wide interfaces with unused methods.
- DIP: High-level logic tied to low-level implementations.
- When you propose a refactor, explain why it improves cohesion/coupling and outline a minimal, safe split.
- If refactor is non-trivial, propose an incremental plan instead of a large rewrite.
3) Removal candidates + iteration plan
- Load
references/removal-plan.md for template.
- Identify code that is unused, redundant, or feature-flagged off.
- Distinguish safe delete now vs defer with plan.
- Provide a follow-up plan with concrete steps and checkpoints (tests/metrics).
4) Security and reliability scan
- Load
references/security-checklist.md for coverage.
- Check for:
- XSS, injection (SQL/NoSQL/command), SSRF, path traversal
- AuthZ/AuthN gaps, missing tenancy checks
- Secret leakage or API keys in logs/env/files
- Rate limits, unbounded loops, CPU/memory hotspots
- Unsafe deserialization, weak crypto, insecure defaults
- Race conditions: concurrent access, check-then-act, TOCTOU, missing locks
- Call out both exploitability and impact.
5) Code quality scan
- Load
references/code-quality-checklist.md for coverage.
- Check for:
- Error handling: swallowed exceptions, overly broad catch, missing error handling, async errors
- Performance: N+1 queries, CPU-intensive ops in hot paths, missing cache, unbounded memory
- Boundary conditions: null/undefined handling, empty collections, numeric boundaries, off-by-one
- Flag issues that may cause silent failures or production incidents.
6) Output format
Structure your review as follows:
## Code Review Summary
**Files reviewed**: X files, Y lines changed
**Overall assessment**: [APPROVE / REQUEST_CHANGES / COMMENT]
---
## Findings
### P0 - Critical
(none or list)
### P1 - High
- **[file:line]** Brief title
- Description of issue
- Suggested fix
### P2 - Medium
...
### P3 - Low
...
---
## Removal/Iteration Plan
(if applicable)
## Additional Suggestions
(optional improvements, not blocking)
Inline comments: Use this format for file-specific findings:
::code-comment{file="path/to/file.ts" line="42" severity="P1"}
Description of the issue and suggested fix.
::
Clean review: If no issues found, explicitly state:
- What was checked
- Any areas not covered (e.g., "Did not verify database migrations")
- Residual risks or recommended follow-up tests
7) Next steps confirmation
After presenting findings, ask user how to proceed:
---
## Next Steps
I found X issues (P0: _, P1: _, P2: _, P3: _).
**How would you like to proceed?**
1. **Fix all** - I'll implement all suggested fixes
2. **Fix P0/P1 only** - Address critical and high priority issues
3. **Fix specific items** - Tell me which issues to fix
4. **No changes** - Review complete, no implementation needed
Please choose an option or provide specific instructions.
Important: Do NOT implement any changes until user explicitly confirms. This is a review-first workflow.
Resources
references/
| File |
Purpose |
solid-checklist.md |
SOLID smell prompts and refactor heuristics |
security-checklist.md |
Web/app security and runtime risk checklist |
code-quality-checklist.md |
Error handling, performance, boundary conditions |
removal-plan.md |
Template for deletion candidates and follow-up plan |
1---2name: code-review-expert3description: Expert code review of current git changes with a senior engineer lens. Detects SOLID violations, security risks, and proposes actionable improvements.4---5
6# Code Review Expert
7
8## Overview
9
10Perform a structured review of the current git changes with focus on SOLID, architecture, removal candidates, and security risks. Default to review-only output unless the user asks to implement changes.
11
12## Severity Levels
13
14| Level | Name | Description | Action |
15|-------|------|-------------|--------|
16| **P0** | Critical | Security vulnerability, data loss risk, correctness bug | Must block merge |
17| **P1** | High | Logic error, significant SOLID violation, performance regression | Should fix before merge |
18| **P2** | Medium | Code smell, maintainability concern, minor SOLID violation | Fix in this PR or create follow-up |
19| **P3** | Low | Style, naming, minor suggestion | Optional improvement |
20
21## Workflow
22
23### 1) Preflight context
24
25- Use `git status -sb`, `git diff --stat`, and `git diff` to scope changes.
26- If needed, use `rg` or `grep` to find related modules, usages, and contracts.
27- Identify entry points, ownership boundaries, and critical paths (auth, payments, data writes, network).
28
29**Edge cases:**
30- **No changes**: If `git diff` is empty, inform user and ask if they want to review staged changes or a specific commit range.
31- **Large diff (>500 lines)**: Summarize by file first, then review in batches by module/feature area.
32- **Mixed concerns**: Group findings by logical feature, not just file order.
33
34### 2) SOLID + architecture smells
35
36- Load `references/solid-checklist.md` for specific prompts.
37- Look for:
38 - **SRP**: Overloaded modules with unrelated responsibilities.
39 - **OCP**: Frequent edits to add behavior instead of extension points.
40 - **LSP**: Subclasses that break expectations or require type checks.
41 - **ISP**: Wide interfaces with unused methods.
42 - **DIP**: High-level logic tied to low-level implementations.
43- When you propose a refactor, explain *why* it improves cohesion/coupling and outline a minimal, safe split.
44- If refactor is non-trivial, propose an incremental plan instead of a large rewrite.
45
46### 3) Removal candidates + iteration plan
47
48- Load `references/removal-plan.md` for template.
49- Identify code that is unused, redundant, or feature-flagged off.
50- Distinguish **safe delete now** vs **defer with plan**.
51- Provide a follow-up plan with concrete steps and checkpoints (tests/metrics).
52
53### 4) Security and reliability scan
54
55- Load `references/security-checklist.md` for coverage.
56- Check for:
57 - XSS, injection (SQL/NoSQL/command), SSRF, path traversal
58 - AuthZ/AuthN gaps, missing tenancy checks
59 - Secret leakage or API keys in logs/env/files
60 - Rate limits, unbounded loops, CPU/memory hotspots
61 - Unsafe deserialization, weak crypto, insecure defaults
62 - **Race conditions**: concurrent access, check-then-act, TOCTOU, missing locks
63- Call out both **exploitability** and **impact**.
64
65### 5) Code quality scan
66
67- Load `references/code-quality-checklist.md` for coverage.
68- Check for:
69 - **Error handling**: swallowed exceptions, overly broad catch, missing error handling, async errors
70 - **Performance**: N+1 queries, CPU-intensive ops in hot paths, missing cache, unbounded memory
71 - **Boundary conditions**: null/undefined handling, empty collections, numeric boundaries, off-by-one
72- Flag issues that may cause silent failures or production incidents.
73
74### 6) Output format
75
76Structure your review as follows:
77
78```markdown
79## Code Review Summary
80
81**Files reviewed**: X files, Y lines changed
82**Overall assessment**: [APPROVE / REQUEST_CHANGES / COMMENT]
83
84---
85
86## Findings
87
88### P0 - Critical
89(none or list)
90
91### P1 - High
92- **[file:line]** Brief title
93 - Description of issue
94 - Suggested fix
95
96### P2 - Medium
97...
98
99### P3 - Low
100...
101
102---
103
104## Removal/Iteration Plan
105(if applicable)
106
107## Additional Suggestions
108(optional improvements, not blocking)
109```
110
111**Inline comments**: Use this format for file-specific findings:
112```
113::code-comment{file="path/to/file.ts" line="42" severity="P1"}
114Description of the issue and suggested fix.
115::
116```
117
118**Clean review**: If no issues found, explicitly state:
119- What was checked
120- Any areas not covered (e.g., "Did not verify database migrations")
121- Residual risks or recommended follow-up tests
122
123### 7) Next steps confirmation
124
125After presenting findings, ask user how to proceed:
126
127```markdown
128---
129
130## Next Steps
131
132I found X issues (P0: _, P1: _, P2: _, P3: _).
133
134**How would you like to proceed?**
135
1361. **Fix all** - I'll implement all suggested fixes
1372. **Fix P0/P1 only** - Address critical and high priority issues
1383. **Fix specific items** - Tell me which issues to fix
1394. **No changes** - Review complete, no implementation needed
140
141Please choose an option or provide specific instructions.
142```
143
144**Important**: Do NOT implement any changes until user explicitly confirms. This is a review-first workflow.
145
146## Resources
147
148### references/
149
150| File | Purpose |
151|------|---------|
152| `solid-checklist.md` | SOLID smell prompts and refactor heuristics |
153| `security-checklist.md` | Web/app security and runtime risk checklist |
154| `code-quality-checklist.md` | Error handling, performance, boundary conditions |
155| `removal-plan.md` | Template for deletion candidates and follow-up plan |