1---
2name: reviewing-code
3description: Reviews code for correctness, security, reliability, performance, and quality. Use when asked to review code, a PR, a diff, changes, or when the user says "review", "code review", or "look over this".
4license: AGPL-3.0-or-later
5metadata:
6 author: Amolith <amolith@secluded.site>
7---
8
9Review code thoroughly, providing constructive and actionable feedback.
10
11## Workflow
12
131. **Gather context**: Understand intent (PR description, commit message, surrounding code, PR comments or email thread)
142. **Identify risk areas**: Auth, payments, migrations, concurrency, external integrations
153. **Analyze systematically**: Prioritize correctness and reliability over style
164. **Report findings**: Use output format; require evidence for each issue
17
18## Review Areas
19
20### Correctness / Behavior (highest priority)
21
22- Does the change match stated intent? Any unintended behavior changes?
23- Edge cases: null/empty, off-by-one, boundary conditions, unicode/encoding
24- State transitions: can objects reach impossible states?
25- Concurrency: races, ordering assumptions, atomicity, async cancellation
26- Backwards compatibility: API contracts, wire formats, schema changes
27- Error semantics: fail open vs closed? Errors propagated correctly?
28
29### Security
30
31Flag only with concrete evidence (source β sink flow or missing boundary check).
32
33- Input validation and sanitization
34- Authentication and authorization at boundaries
35- Injection: SQL, XSS, command, SSRF, path traversal
36- Insecure deserialization, open redirects
37- Crypto misuse: weak randomness, homegrown crypto, token handling
38- Secrets/credentials: hardcoded or logged
39- Multi-tenant isolation, authorization gaps
40- New dependencies: overly broad permissions, supply chain risk
41
42### Reliability / Operability
43
44- Timeouts, retries, backoff, circuit breaking
45- Idempotency (jobs, webhooks, payments)
46- Resource cleanup: files, sockets, connections, cancellation
47- Logging/metrics: enough to debug? No secrets/PII logged?
48- Configuration: safe defaults, env var handling
49
50### Data / Persistence
51
52- Transaction boundaries, isolation, partial writes
53- Schema/migrations: locking, backfills, rollback safety
54- Query efficiency: N+1, missing indexes, incorrect joins
55
56### Performance
57
58Flag only with clear hotspot evidence (loops over large input, repeated I/O, known N+1).
59
60- Algorithm complexity and bottlenecks
61- Memory allocation patterns
62- Unnecessary computations
63
64### Code Quality
65
66Style issues are **nits**βonly mention if they violate local conventions or materially harm readability.
67
68- Naming and style consistency with codebase
69- Function/class size and single responsibility
70- Error handling completeness
71- Dead code, unused imports
72
73### Testing
74
75- Coverage for new/changed code paths
76- Edge cases and error paths tested
77- Test clarity
78
79## Output Format
80
81```markdown
82## π΄ Must Fix
83
84### [Issue title]
85
86**Location:** `path/to/file.ts:42`
87
88**Impact**
89
90[What breaks or could break]
91
92**Evidence**
93
94[Concrete code path or condition that triggers this]
95
96**Fix**
97
98[Suggested solution]
99
100## π Should Fix
101
102[Medium confidence or meaningful impact]
103
104## π‘ Consider
105
106[Trade-offs, optional improvements]
107
108## π¬ Questions
109
110[When intent is unclear: ask, don't assert]
111
112## π Nits
113
114[Style-only, keep brief or omit]
115
116## β
Strengths
117
118[What's done well, keep brief]
119```
120
121Omit empty sections. For small clean changes, "Looks good" suffices.
122
123## Anti-Noise Rules
124
125- **Correctness over style**: Don't request refactors unless they reduce bug risk
126- **Evidence required**: Each must-fix needs a concrete trigger condition
127- **Ask vs assert**: When uncertain, ask a question and describe the risk
128- **No hypotheticals**: Avoid speculative performance/security concerns without evidence
129- **Respect local conventions**: Check surrounding code before flagging style