, the working tree, staged changes, or the latest commit.
If the target is a spec, check whether decisions, invariants, requirements, error behavior, and tests are reviewable before code exists.
If the target is code, read the actual changes and any available context that explains intent, such as the spec, plan, commit message, or PR title and description.
, ordered highest risk first. A clean review is a valid outcome.
Verification
Every finding is tied to concrete evidence in the target
Every finding explains why it matters
Findings are limited to the changes under review
Highest-risk findings come first
Pre-existing issues are not mixed in
No finding is just a style preference
Rules
Prioritize real bugs and regressions over style commentary.
Flag changes that add unnecessary surface area.
Flag silent contract changes.
Flag decisions made in code that were not surfaced in the spec when they affect behavior or maintenance.
Flag invariants that were omitted from a spec or quietly broken by an implementation.
Flag missing or weak failure-path handling when it matters.
Flag reviewer-facing context that is missing or misleading when it would make the change hard to review, such as a PR title or description that does not explain what changed and why.
If there is no concrete diff, file, or commit to review, say so.
Findings only. Do not fix the code.
Be direct and specific.
Tie each finding to evidence in the diff.
Do not speculate without evidence.
If you are unsure a problem is real, say so honestly.