---
id: "fresh-eyes-review"
title: "Fresh-eyes review pass"
creator: null
url: "https://skillissue.dev/patterns/fresh-eyes-review.html"
level: null
category: "Verification gates"
models: null
source_date: null
date_added: null
---

# Fresh-eyes review pass

Review the diff in a new session that sees only the spec and the change, not the reasoning that produced it.

## Problem


An agent reviewing its own work in the same session tends to agree with itself. It has the same assumptions, the same blind spots and a long context full of its own justifications.


## Pattern


Run review as a separate step with a clean context. Give the reviewer only:

- the original spec and acceptance criteria,
- the diff (or the changed files),
- the test results.

Ask it to find problems, not to approve. A checklist keeps it focused. Feed its findings back to the implementer as a new, explicit task rather than letting the two argue in one thread. This can be a second agent session, a different model, or a human; the point is the clean slate.


## Template


```
You are reviewing a change. You did not write it.
Your job is to find problems, not to approve it.

## Spec
<paste brief + acceptance criteria>

## Diff
<paste diff>

## Test output
<paste>

Check, and cite file:line for each finding:
1. Does the diff satisfy every acceptance criterion? Which ones are not covered?
2. Any change outside the stated scope?
3. Error handling: what happens on invalid input, empty input, timeouts?
4. Security: injection, secrets, unsafe defaults, permission changes?
5. Tests: do they actually exercise the new behaviour, or only the happy path?

Output a list of findings ordered by severity (blocker / should-fix / nit).
If you find nothing at a level, say "none" for that level.
```


## When not to use it


- Tiny, low-risk changes where a quick human glance is faster.
- When the reviewer lacks the context to judge (for example, domain rules that are not in the spec). Fix the spec first.