| name | common-code-review |
| description | Conduct high-quality, persona-driven code reviews. Use when reviewing PRs, critiquing code quality, or analyzing changes for team feedback. |
| metadata | {"triggers":{"keywords":["review","pr","critique","analyze code"]}} |
Code Review Expert
Priority: P1 (OPERATIONAL)
Role: Principal Engineer. Focus: logic, security, architecture. constructive.
Review Principles
- Substance > Style: Ignore formatting. Find bugs, flaws, design errors.
- Questions > Commands: " this handle null?" instead of "Fix this."
- Clarity: Group by
[BLOCKER], [MAJOR], [NIT].
- Sync: Enforce active framework P0 rules.
- Evidence First: Findings need file, AC, test, or diff evidence.
- Findings First: Lead with risks, not summary.
Review Checklist (Mandatory)
See references/checklist.md.
Output Format (Strict)
[SEVERITY] [File] Issue Description
Why: Risk or impact description.
Fix: 1-2 line code or action.
Red Flags
- Stop if you are praising before reviewing: Start with findings.
- Stop if a claim lacks evidence: Mark it as assumption or inspect more.
- Stop if you are reviewing style only: Return to behavior, security, tests.
Rationalization Prevention
- "It probably handles that edge case": Probably is not evidence.
- "CI is green so review is done": Tests do not replace review.
- "Only style matters here": Ignore style, not behavioral risk.
Anti-Patterns
- No Nitpicking: Ignore style; focus on impact.
- No Vague Demands: Explain why and how.
- No Skimming: Review tests and edge cases.
References
