Think about the last time you merged a PR without a proper review.
Maybe tests passed. Maybe it looked fine at a glance. Maybe you were moving fast and told yourself you'd clean it up later.
Then two weeks later, a bug surfaces. Or a junior dev inherits the code and spends a day trying to understand it. Or a security scanner flags something in a production deploy.
"Looked fine" is not a review. It's a hope.
This is Part 2 of the copilot-workflow series. Part 1 covered setting up the template. This one covers using @code-reviewer — the staff engineer persona that reviews every change before it touches main.
The Problem With Most Code Review
Code review fails in two ways.
It gets skipped. You're the only dev on a project, or the team is moving fast, or "it's just a small change." The PR merges without anyone really looking at it.
It gets rubber-stamped. Someone glances at the diff, sees nothing obviously on fire, and clicks Approve. This catches maybe 20% of real issues — the obvious ones. The subtle ones sail through.
What you actually need is a reviewer who checks multiple dimensions systematically. Not just "does this work" but also "is this readable," "does this fit the architecture," "is there a security hole," "will this cause a performance problem at scale."
That's what @code-reviewer does.
The 5-Axis Review Framework
Think of your code like a restaurant being health-inspected.
A good inspector doesn't just taste the food. They check the kitchen temperature (correctness), whether the menu is readable (readability), whether the kitchen layout makes sense (architecture), whether hygiene standards are met (security), and whether the kitchen can handle a full service (performance).
Pass all five. Not just one.
| Axis | The question | What it catches |
|---|---|---|
| Correctness | Does it do what it claims? | Edge cases, error paths, off-by-one errors, race conditions |
| Readability | Can a stranger understand it? | Confusing names, deeply nested logic, missing context |
| Architecture | Does it fit the system? | Circular dependencies, wrong abstraction level, code duplication |
| Security | Can it be exploited? | Unvalidated input, SQL injection, exposed secrets, missing auth checks |
| Performance | Will it survive load? | N+1 queries, unbounded loops, missing pagination, blocking operations |
The Labeling System That Changes Everything
Most review feedback is undifferentiated. Everything comes in as a comment and you have no idea what's blocking the merge vs. what's a nice-to-have. So you either fix everything (slow) or fix nothing (wrong).
@code-reviewer labels every finding:
| Label | Meaning | What to do |
|---|---|---|
| Critical | Blocks merge. Security vulnerability, data loss risk, broken functionality. | Fix before the PR goes anywhere. |
| Important | Should fix before merge. Wrong abstraction, missing test, poor error handling. | Fix unless you have a very good reason not to. |
| Suggestion | Optional improvement. Naming, style, minor optimization. | Take it or leave it. Your call. |
This means you read the review once and immediately know your priority order. No guessing what the reviewer considers urgent.
How to Use It
Basic review
@code-reviewer Review the changes in src/auth/login.ts
Give it context — better output
@code-reviewer Review src/auth/login.ts — this adds JWT refresh token rotation.
Focus on the token storage and the edge case where both tokens expire simultaneously.
The more context you give, the more targeted the output. Tell it what changed and what you're worried about.
Review a whole feature
@code-reviewer Review the changes across src/api/users/ and src/middleware/auth.ts —
this is a new role-based access control system. The spec said admin users should
be able to manage other users but not delete their own account.
Paste a diff directly
For small changes, paste the diff straight into chat:
@code-reviewer Review this change:
- const user = await db.query(`SELECT * FROM users WHERE id = ${userId}`);
+ const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
Is this fix complete or are there other injection vectors in this file?
What the Output Looks Like
Here's a real-world example. Imagine you've written a password reset endpoint:
app.post('/api/auth/reset-password', async (req, res) => {
const { token, newPassword } = req.body;
const user = await db.query(`SELECT * FROM users WHERE reset_token = '${token}'`);
if (!user) return res.status(404).json({ error: 'Invalid token' });
await db.query(`UPDATE users SET password = '${newPassword}' WHERE id = ${user.id}`);
res.json({ success: true });
});
Ask @code-reviewer to review it. You'll get something like this:
Verdict: REQUEST CHANGES
Overview: Password reset endpoint with multiple critical security vulnerabilities and missing validation. Do not merge.
Critical Issues
-
Line 3— SQL injection via string interpolation in token lookup. Use parameterized query:db.query('SELECT * FROM users WHERE reset_token = $1', [token]) -
Line 5— Password stored as plaintext. Hash with bcrypt before storing:await bcrypt.hash(newPassword, 12) -
Line 5— Second SQL injection in UPDATE statement. Parameterize both values. - Missing — Reset token not invalidated after use. An attacker who intercepts the token can reset the password again.
- Missing — No token expiry check. Tokens should expire after 15-30 minutes.
Important Issues
- Missing — No rate limiting on this endpoint. Brute-force token guessing is possible.
- Missing — No input validation on
newPassword. Minimum length, complexity requirements should be enforced. -
Line 4— Error message reveals whether a token exists. Return a generic message regardless of outcome to prevent token enumeration.
Suggestions
- Consider logging password reset events to an audit log (user ID, timestamp, IP).
What's Done Well
- Endpoint is correctly unauthenticated — password reset flows shouldn't require a logged-in session.
That is what a real review looks like. Five critical issues. Two important ones. A genuine suggestion. All labeled. Priorities clear.
Without this review, that code merges and your users' passwords are stored in plaintext with SQL injection vulnerabilities.
When to Invoke It
Before every PR — no exceptions. This is the rule.
The cost is one @code-reviewer message. The cost of skipping it is a production incident, a security breach, or a codebase that quietly becomes harder to maintain.
Three situations where it's especially valuable:
1. Code you wrote quickly. When you're moving fast you make tradeoffs. The reviewer surfaces those tradeoffs before they become permanent.
2. Code another AI generated. Copilot autocomplete, ChatGPT, whatever. AI-generated code is confident and plausible even when wrong. It needs more scrutiny, not less.
3. Code in unfamiliar territory. If you're writing auth logic but auth isn't your specialty, @code-reviewer + @security-auditor in combination is an extremely strong safety net.
The Mental Shift
Here's what changes when you run @code-reviewer consistently.
You stop thinking "does this work?" and start thinking "is this ready?" Those are different questions. Code can work and still be wrong — wrong for maintainability, wrong for security, wrong for the next engineer who has to touch it.
A passing test suite tells you the code does what you tested. The 5-axis review tells you whether it's actually ready to ship.
Get the Template
This agent is part of the copilot-workflow template — one setup, works in every repo you create from it.
👉 github.com/panditAbhis/copilot-workflow
Next in the series: Part 3 covers @test-engineer and the Prove-It Pattern — how to write a failing test that proves a bug exists before you touch a single line of fix code.
If this was useful, follow for the rest of the series and drop a ⭐ on the repo.
Series navigation
Top comments (0)