You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .codex/review-prompt.md
+16-5Lines changed: 16 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,10 +24,11 @@ When both exist, report blockers first.
24
24
25
25
### Review Method
26
26
27
-
Do two passes:
27
+
Do three passes:
28
28
29
-
1.**Blockers pass** — Scan for correctness bugs, security issues, API/schema contract breaks, missing migrations, data integrity risks, and missing tests for changed behavior. These are `🔴 Bug` comments.
30
-
2.**Maintainability pass** — Scan for code bloat, readability issues, naming problems, pattern violations, hardcoded values. These are `🟡 Issue`, `🔵 Nit`, or `💡 Suggestion` comments.
29
+
1.**Context + risk-map pass (mandatory)** — Read full touched files (not only hunk lines) and identify high-risk zones: platform/runtime boundaries, event handlers, async cleanup (`finally`), auth/validation boundaries, and repeated predicates/guards.
30
+
2.**Blockers pass** — Scan for correctness bugs, security issues, API/schema contract breaks, missing migrations, data integrity risks, and missing tests for changed behavior. These are `🔴 Bug` comments.
31
+
3.**Maintainability pass** — Scan for code bloat, readability issues, naming problems, pattern violations, hardcoded values, and architecture drift in touched areas. These are `🟡 Issue`, `🔵 Nit`, or `💡 Suggestion` comments.
31
32
32
33
### Comment Gate
33
34
@@ -53,9 +54,12 @@ If any check fails, skip the comment.
53
54
- Boundary conditions — empty arrays, null inputs, zero values, maximum values.
54
55
- Error handling — swallowed errors, missing error propagation, unhelpful error messages. Do not flag missing error handling for internal code that cannot reasonably fail.
55
56
- Streaming/multipart handlers — verify a request cannot send multiple responses (e.g., multi-file parts triggering repeated `res.json()` calls). If a route expects one file, ensure parser limits and single-response guards exist.
57
+
- Unsafe runtime assumptions hidden by type assertions (`as ...`, `as any`, non-null `!`) when values come from events, external I/O, or platform-specific APIs.
58
+
- Platform/runtime compatibility assumptions — usage of globals/APIs (`window`, `document`, `Node`, `process`, browser-only APIs) in cross-runtime code paths must be guarded.
56
59
57
60
#### Security
58
61
62
+
59
63
- Injection risks (SQL, command, XSS) when handling user input.
60
64
- Hardcoded secrets — API keys, passwords, tokens in code.
61
65
- Missing input validation at system boundaries (user input, external APIs). Not for internal function calls.
@@ -77,18 +81,25 @@ If any check fails, skip the comment.
77
81
- Changed behavior must have updated tests reflecting the new expectations.
78
82
- If tests are present but brittle (testing implementation details rather than behavior), flag it.
79
83
- For single-file upload endpoints, look for regression coverage of multi-file/malformed multipart inputs and confirm no double-response behavior.
84
+
- Prefer tests that validate production behavior directly. If a test re-implements production decision logic locally, and could stay green while runtime behavior regresses, flag it and suggest importing shared runtime logic or testing via a higher-level behavior path.
80
85
81
86
Missing tests for changed behavior are blockers (`🔴 Bug`) only when the change affects user-facing behavior, API contracts, or data integrity. Missing tests for internal refactors or trivial changes are `🟡 Issue`.
82
87
83
88
### Pass 2: Maintainability
84
89
90
+
#### Architecture Direction (Touched Area)
91
+
92
+
- Evaluate whether the diff makes the touched area more or less maintainable (coupling, cohesion, readability of control flow).
93
+
- Flag **architecture drift** when business decisions become more scattered (same guard/predicate duplicated across multiple call paths, UI/state/network logic further entangled, or test/runtime logic diverging).
94
+
- When the same invariant-like predicate appears repeatedly in changed code, prefer a named helper/shared utility if it clearly reduces divergence risk.
95
+
85
96
#### Code Bloat and Unnecessary Complexity
86
97
87
98
-**Excessive code** — More lines than necessary. Could this be done in fewer lines without sacrificing clarity?
88
99
-**Over-engineering** — Abstractions, helpers, or utilities for one-time operations. Premature generalization. Feature flags or config for things that could just be code.
-**Duplicate code** — Same logic repeated instead of extracted. But do not suggest extraction for only 2-3 similar lines — that is premature abstraction.
102
+
-**Duplicate code** — Same logic repeated instead of extracted. Do not suggest extraction for only 2-3 similar lines unless the repeated logic encodes a correctness invariant across multiple paths (e.g., identical guard logic in multiple `finally` blocks).
92
103
93
104
#### Readability and Naming
94
105
@@ -169,4 +180,4 @@ The `line` field must refer to the line number in the new version of the file (r
169
180
170
181
## Summary
171
182
172
-
Write a brief (2–4 sentence) overall assessment in the `summary` field. Lead with blockers if any exist. Mention whether the PR is clean/minimal or has code quality issues. If the PR looks good, say so.
183
+
Write a brief (2–4 sentence) overall assessment in the `summary` field. Lead with blockers if any exist. Mention whether the PR is clean/minimal or has code quality issues. Include one sentence on maintainability direction in touched areas (improved / neutral / worsened, and why). If the PR looks good, say so.
0 commit comments