Code review criteria — the five review axes, core principles, severity format, and verdict for reviewing code changes. Loaded by the reviewer subagent of the review-code flow. Not a user-facing flow — to review code, use the review-code flow.
SkillScore88Maintained
Automatic
◆Coding pack
Last verified 10/10/2026
What it changes
Passed 21 of 24 test cases with the skill, and 17 of 24 without it.
Without skill71%
With skill88%
Checks it passed that the model alone missed
Assigns F1 and F2 to the critical security flaws.
Requires limiting dependency upgrades to one package per change.
Assigns the Critical: prefix to the SQL injection vulnerability.
and 6 more in the full report
5 fixed16 passed either way2 still failing1 broke
Pass-rate lift
+17 pp
Tokens
+139%
Agent turns
0%
Response time
-41%
Model gemini-3.6-flashMeasured 10/10/2026v121 of 24 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
A reviewer needs to assign severity prefixes to four findings: an unauthenticated SQL injection vulnerability, a null-pointer exception on empty array input, a non-optimal nested loop, and a variable naming preference. Which standardized prefix should be assigned to each finding?
What was checked, without and with the skill
Checked
Without skill
With skill
Assigns the Critical: prefix to the SQL injection vulnerability.
Missed
Passed
Assigns the High: prefix to the unhandled null-pointer exception.
Missed
Passed
Assigns the Low: or Suggestion: prefix to the variable naming preference.
Missed
Passed
case-17 · gemini-3.6-flash · 10/10/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md241 linessingle file
Code Review Criteria and Quality
Overview
Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.
The approval standard: Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.
When to Use
The reviewer subagent of the review-code flow loads this skill to perform
the review of a code change.
To review code, always go through the review-code flow — never load this
skill directly for that. This is the criteria reference, not the flow.
Core Principles
These principles underpin every axis. When in doubt, default to them.
DRY (Don't Repeat Yourself): Every piece of knowledge has one authoritative representation. If the same logic appears in two places, extract it into a shared helper, model, or type. Reviewers: flag duplicated logic as a required change — it's not "just similar," it's drift that will diverge.
KISS (Keep It Simple, Stupid): The simplest solution that works is the best solution. Complexity must earn its place. Reviewers: if you need more than one sentence to explain what a piece of code does, it's too complex — push for simplification before merge.
YAGNI (You Aren't Gonna Need It): Don't add abstractions, hooks, or generalizations for hypothetical future use cases. Generalize on the third occurrence, not the first. Reviewers: delete speculative generality.
Don't invent problems: Do not manufacture issues to produce more feedback. Every finding must be a real risk, a real readability barrier, or a real architectural concern — not a hypothetical or a stylistic preference disguised as a problem.
The Five-Axis Review
Every review evaluates code across these dimensions.
1. Correctness
Does the code do what it claims to do?
Does it match the spec or task requirements?
Are edge cases handled (null, empty, boundary values)?
Are error paths handled (not just the happy path)?
Does it pass all tests? Are the tests actually testing the right things?
Are there off-by-one errors, race conditions, or state inconsistencies?