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.

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:

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