4 steps to an agent that reviews your code before it merges

The idea

A US cyber agency reportedly runs an Anthropic model that scans government code for weaknesses. The question is no longer whether people use agents, it's who checks the code they write for you. You do not need a government for this. You need one review agent and one gate on your code.

• The agent that writes the code does not review itself. Review comes from a clean context.
• Review runs on the diff only, not on the whole project.
• A serious finding stops the merge instead of slipping in quietly.
• It's the same rule as Snyk: you don't say 'done' when there's an open hole.

Step 1: define a review skill

Don't ask for a review with a one-off prompt every time. Turn it into a standing skill with a clear role, one that reads only the change and returns only problems.

• Give it one role: security and code reviewer, not a code writer.
• It doesn't fix. It only flags and rates severity.
• The output is short: issue, location, severity, why it's risky.
• Save it as a skill so every run looks the same.

# Skill: code-audit

You are a security and code review agent.

Role:
- Read only the change (the diff), not the whole project.
- Do not write or fix code.
- Find security weaknesses, bugs, and broken behavior.
- Rate every finding: low / medium / high / critical.

Return a table only:
1. The issue.
2. The file and line.
3. The severity.
4. Why it is risky, in one sentence.

If there are no issues: write "No findings."

Step 2: let it read the diff

Don't dump the whole codebase on it. Give it exactly what changed. That's cheaper, more focused, and stops it from inventing problems in code nobody touched.

• Feed it the diff of the change about to land, not the repo.
• Staged only: what's actually about to merge right now.
• Large files? Trim to the changed region.
• Attach the minimal context needed to understand the change.

# What the agent gets, nothing more
git diff --staged > change.diff

# Run the review on the diff only
agent: audit change.diff

Step 3: flag weaknesses

This is the core. The agent goes over the change with a fixed checklist of things that blow up in production. If you use a scanning tool like Snyk, this is the step where you run it on the change and fold in the findings.

• Secrets and tokens that got into the code by mistake.
• User input that wasn't validated: SQL injection, XSS, path traversal.
• Permissions and access control: who's allowed to touch what.
• New dependencies with a known vulnerability.
• Breaking existing behavior or deleting data unintentionally.

# Example review output

| # | Issue | File | Severity |
|---|------|------|--------|
| 1 | API token in code | config.ts:14 | critical |
| 2 | Unsanitized input in query | db.ts:52 | high |
| 3 | Console log with user data | api.ts:88 | low |

Step 4: stop before merge

A finding without a gate is just a comment nobody reads. The simple rule: high or critical stops the merge. Everything comes back to you for a decision, and you're the one who releases it, not the agent.

• high or critical = stop. No merge until it's fixed or manually approved.
• low and medium get logged but don't block.
• The agent doesn't approve itself, you release the gate.
• Wire it into pre-merge or pre-commit so it runs on its own every time.

# The gate rule

If there is a high or critical finding:
  -> Stop. Do not merge.
  -> Return the list to the developer.
Otherwise:
  -> Log the findings.
  -> Allow the merge to proceed.

The full template in one run

This is what the whole chain looks like in practice. Four steps, one skill, one gate. You paste this at the end of every code task before it lands.

Before merging any change:

1. Review skill active (code-audit).
2. git diff --staged  ->  this is the only input.
3. The agent scans: secrets, unsanitized input, permissions, dependencies, broken behavior.
4. high/critical finding  ->  stop before merge. Everything comes back to me.

One rule: no merge when there is an open hole.

Checklist before you rely on this

• The skill reads only the diff, it doesn't invent problems in code you didn't touch.
• Every finding has a severity rating, not just a flat list.
• high and critical actually stop the merge, not just print a warning.
• You release the gate manually, the agent doesn't approve itself.
• If you have a scanning tool like Snyk, it runs on the change and its findings feed into the review.