Review code changes for bugs, security issues, performance problems, and style before shipping.
SkillScore95Maintained
Automatic
◆Coding pack
Last verified 8/4/2026
What it changes
Passed 21 of 22 test cases with the skill, and 15 of 22 without it.
Without skill68%
With skill95%
Checks it passed that the model alone missed
Includes explicit 'Why:' header line in findings
Includes explicit 'Fix:' header line in findings
Includes explicit 'What:' header line in findings
and 5 more in the full report
6 fixed15 passed either way1 still failing0 broke
Pass-rate lift
+27 pp
Tokens
+137%
Agent turns
0%
Response time
-2%
Model gemini-3.6-flashMeasured 8/4/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
Review this helper function diff in 'utils/math.ts':
```typescript
export function calc(a: number, b: number): number {
const x = a * 0.15;
return x + b;
}
```
The variable name 'x' represents tax amount but is poorly named. Format the issue using the strict severity classification scheme.
What was checked, without and with the skill
Checked
Without skill
With skill
Classifies unclear variable naming 'x' as [MINOR] or [SUGGESTION]
Missed
Passed
case-18 · gemini-3.6-flash · 8/4/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md234 linessingle file
Code Review
Approach every review as a staff engineer whose name is on the production incident if this code ships broken. You are not here to enforce style preferences or score points — you are here to find the bugs that CI does not catch, the security holes that are not obvious, and the design decisions that will cost ten times more to fix in six months.
A good review makes the code safer, clearer, and more maintainable. It also teaches. Every finding should explain not just what is wrong but why it matters and how to fix it.
Reviewer Principles
Find bugs, not preferences. Distinguish clearly between issues that must be fixed before shipping and suggestions that would be nice. Never block a PR on personal style preference.
Read the code, not the diff. The diff shows what changed. The code shows what it does. Read both. A change that looks harmless in the diff often makes no sense in the full file context.
Assume good intent, question logic. The author is not incompetent — they may have constraints you do not know about. Ask before concluding.
The test suite is part of the review. A PR without tests is an incomplete PR. A PR with tests that do not cover the changed logic is a PR that ships untested code.
One pass is not enough. First pass: understand what the code does. Second pass: find what can go wrong. Third pass: check tests, docs, and integration points.
Review Execution Order
Work through every review in this order. Do not skip sections.
Pass 1 — Context & Intent (2 minutes)
Before reading a single line of code:
What is this PR supposed to do? Read the description, ticket, or commit message.
Is the scope right? A PR that touches 20 files for a "small bug fix" is a red flag.
What are the highest-risk areas? Auth changes, data migrations, payment flows, external API integrations — these get extra scrutiny.
Pass 2 — Logic & Correctness
Read the code looking for:
Wrong behaviour — does the code do what the description says?