3.4KB
Review
Version: 1.0.0
Purpose
Review completed work for correctness, regression risk, maintainability, security, and consistency with the project's existing behavior.
This review occurs after implementation.
It does not replace execution or testing.
Review Context
Before reviewing, understand:
REQUESTED CHANGE
ACTUAL CHANGE
FILES MODIFIED
VERIFICATION ALREADY PERFORMED
IMPORTANT PROJECT CONSTRAINTS
Inspect the resulting diff when available.
Review Areas
Evaluate only relevant areas.
Correctness
Check:
Does the implementation satisfy the request?
Does the logic do what it claims?
Are important branches handled?
Are errors handled appropriately?
Regression Risk
Ask:
What existing behavior could this change unintentionally affect?
Inspect:
callers
shared code
public APIs
database behavior
configuration
routes
file formats
authentication
when relevant.
Project Consistency
Check whether the implementation follows established:
architecture
naming
error handling
configuration
data access
testing
logging
Do not recommend a different architecture merely because another pattern is personally preferable.
Security
When relevant, inspect:
authentication
authorization
input validation
output encoding
SQL injection
command injection
path traversal
secret handling
privilege boundaries
Do not manufacture security findings without evidence.
Data Integrity
For data changes inspect:
transactions
null handling
duplicates
type conversion
row counts
partial writes
referential integrity
Maintainability
Look for:
unnecessary duplication
hidden side effects
magic values
poor naming
unnecessary abstraction
unnecessary dependencies
complexity without benefit
Verification
Check:
Were appropriate tests actually run?
Does the verification prove the important behavior?
Was only the happy path tested?
What remains unverified?
Do not accept:
"This should work."
as verification evidence.
Diff Hygiene
Inspect for:
accidental deletions
formatting churn
debug code
temporary files
hardcoded credentials
unrelated edits
stale comments
generated files accidentally committed
Finding Classification
Classify findings as:
BLOCKER
IMPORTANT
OPTIONAL
Blocker
Must be resolved before completion.
Important
Should be addressed because it creates meaningful risk.
Optional
Improvement that is useful but not required for correctness.
Do not inflate optional preferences into blockers.
Finding Format
For each meaningful finding:
### Finding
Severity:
[...]
Location:
[...]
Issue:
[...]
Why It Matters:
[...]
Recommended Change:
[smallest appropriate correction]
No-Issue Result
It is acceptable to conclude:
No blocking or important issues found.
Do not invent findings to justify the review.
Red-Team Routing
If the task is consequential and normal review passes, invoke:
.ai/skills/red-team/SKILL.md
for the relevant adversarial perspective.
Output
Return:
## Review Result
PASS
or
CHANGES REQUIRED
## Blockers
[...]
## Important Findings
[...]
## Optional Improvements
[...]
## Verification Notes
[...]
Omit empty sections when they add no value.