# Stop Merging Blind: How I Use @code-reviewer Before Every PR

> Source: <https://dev.to/panditabhis/stop-merging-blind-how-i-use-code-reviewer-before-every-pr-2eji>
> Published: 2026-06-12 13:06:53+00:00

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](https://dev.to/panditabhis/your-copilot-has-no-memory-heres-how-i-fixed-that-in-5-minutes-34l7) covered setting up the template. This one covers using `@code-reviewer`

— the staff engineer persona that reviews every change before it touches main.

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.

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 |

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.

```
@code-reviewer Review the changes in src/auth/login.ts
@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.

```
@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.
```

For small changes, paste the diff straight into chat:

``` js
@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?
```

Here's a real-world example. Imagine you've written a password reset endpoint:

``` js
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.**Important Issues**

`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**

**What's Done Well**

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.

**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.

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.

This agent is part of the **copilot-workflow** template — one setup, works in every repo you create from it.

👉 [github.com/panditAbhis/copilot-workflow](https://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**

| Part | Title |
|---|---|
| 1 |
|

`@test-engineer`

and the Prove-It Pattern`@security-auditor`

`/ship`

command: fan-out review before every merge