Every substantive finding must include the literal `Why:` field. If code or a diff is missing, state the evidence needed before offering a substantive finding.
[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
Output Templates
Full Checklist
Canonical response anchors
When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:
BLOCKER
Check
MAJOR
edge cases
tests
How to use it
Copy the folder
Take hoangnguyen0403/common-code-review from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
Check the name does not clash
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.