/fresh-eyes

name: fresh-eyes
description: '[Adam''s Skills] Fresh-context audit of a finished diff against the conversation''s stated intent. A subagent with zero conversation history reviews the diff blind — reporting what it believes the change does, its quality, and any oversights — then the main context reconciles that blind read against what the work was actually meant to do, and surfaces any assumption about real-world behaviour that the code cannot settle. Use when a chunk of work is complete and you want fresh eyes to confirm nothing was missed, scope is fully covered, and no oversights or bugs slipped through, before moving on or shipping.'

fresh-eyes

Audit a finished diff with fresh eyes. The mechanism is **double-blind reconciliation**: a subagent that never saw the conversation reads the diff blind and reports what it *thinks* the change does. The main context — which holds the real intent — compares that blind read against what the work was meant to do. The divergence is the signal.

Not *only* a bug-hunt. The primary lens is completeness and intent — did the change do what it was meant to, fully. Catching bugs and oversights is a secondary byproduct of that check, welcome but not the goal. For a dedicated correctness sweep, use `/code-review` or `/codex review` instead.

**Why this is not the verification pass you were told to delete.** Current prompting guidance says to strip explicit verification instructions — "double-check your answer", "add a final verification step", "use a subagent to verify" — because the model already self-checks and the instruction compounds into wasted passes. That is correct, and it does not describe this skill. Those instructions ask the *same* context to look at its own work again, which is the pass that adds nothing. This skill's value is not the second look; it is that the second reader **has never seen the conversation**, so it cannot inherit the premise the first reader was working from. That is a different instrument, and no amount of self-checking substitutes for it. Keep the isolation; it is the whole mechanism. What the guidance *does* bite on here is quantity — see the fan-out guardrail below.

**Know what this instrument cannot see.** It measures the gap between two readings, so it is blind to any error the two share. If the intent itself is wrong, a faithful implementation of it produces zero divergence — the strongest possible pass. Agreement is therefore evidence that the code expresses the intent, never evidence that the intent was right. Steps 1, 3 and 4 exist to attack that blind spot directly; do not water them down.

Workflow

Run these steps in order. Do not skip step 1 — it is the integrity gate.

1. **Pre-register intent (BEFORE any review).** Write down, in the conversation, a short brief of what we set out to do. This must happen before reading the blind report, or the main context will rationalize the blind read into false agreement and the signal is lost. Split the brief in two:

• **Asked** — what the user actually requested. In scope and out of scope.
• **Derived** — everything else that ended up in scope: proposed by a prior review,

by a subagent, or by your own inference. Tag each item with where it came from and what it rests on — a **domain fact** (someone knew how the world actually behaves) or **code shape** (the types, names, or structure suggested it).

Keeping these apart is the point. A wrong premise almost never enters through the *Asked* list; it enters as a code-shape derivation that everyone downstream then treats as settled. Show the brief to the user.

2. **Capture the change to audit.** Try these sources in order; use the first that yields a non-empty change:

• **Override arg** (if given): a commit range, `--staged`, or an explicit path.
• **Git, uncommitted:** working changes exist → `git diff HEAD`.
• **Git, branch vs base:** no uncommitted changes → `git diff <base>...HEAD`, where

`<base>` is the repo's default branch (resolve via `git symbolic-ref refs/remotes/origin/HEAD`, fall back to `main` then `master`, or ask the user if none resolve).

• **Fallback — no git / not a repo / empty diff:** reconstruct the change from THIS

session. Collect the files you created or edited this session and assemble their content (or a synthetic before/after diff) as the material to review. This is the common case for changes that were never committed to git. If you cannot reconstruct it, ask the user to point at the changed files or paste the diff — do not guess.

Whatever the source, the output of this step is a concrete diff or set of changed files to hand to the blind agent in step 3 — never the conversation itself.

3. **Spawn a fresh-context subagent (the Agent tool, `general-purpose` or `Explore`).** Give it ONLY the diff or changed files from step 2 — never conversation history, even when the change was reconstructed from this session. Its blind read is the point. See [REFERENCE.md](REFERENCE.md) for the exact subagent prompt. It must report:

• What it believes this change does / fixes / builds.
• How well it is implemented (clarity, structure, tests).
• Oversights, bugs, missed edge cases, and shadow paths (nil / empty / error inputs).
• **Assumptions about the world** the change depends on but cannot prove, including

any behaviour it makes narrower or stricter.

If the subagent fails, times out, or returns nothing usable, retry once. If it still fails, tell the user and stop — never fabricate a blind read to fill the gap.

4. **Reconcile.** Compare the blind report against your pre-registered intent. Where the agent's understanding diverges from what you meant = dropped scope, or an implementation that does not express the intent. That divergence is the headline.

Then work the *Derived* list, which divergence alone will never flag. For each item tagged **code shape*