Fresh eyes review

Let a sub-agent review the code

Ask an AI agent to review the code it just wrote, and it will not find much. Show the same changes to a fresh session, and it will return with many more findings. Some valid, some minor, others just noise. Even the best models behave like this: the authoring session is biased by its own reasoning.

After all, people are no different: finding mistakes in your own text is hard, while a colleague often spots them more easily. This skill gives your agent that colleague: a sub-agent that starts with a clean context.

Authoring session The session that did the work (or has the reference: the TICKET, REQUIREMENTS, PLAN, etc.) and knows the goal. This is where you launch /fresh-eyes-review.
Receives the findings from the reviewing session and judges them, recommending which ones to address.
Reviewing session A clean context: it sees the changes, has full access to the codebase, and gets a summary of the goal (or the TICKET). It never sees the authoring session's reasoning: no PLAN or similar docs.
the changes and their goal the findings
Authoring session The session that did the work (or has the reference: the TICKET, REQUIREMENTS, PLAN, etc.) and knows the goal. This is where you launch /fresh-eyes-review.
↓ the changes and their goal
Reviewing session A clean context: it sees the changes, has full access to the codebase, and gets a summary of the goal (or the TICKET). It never sees the authoring session's reasoning: no PLAN or similar docs.
↓ the findings
Authoring session Receives the findings from the reviewing session and judges them, recommending which ones to address.

fresh-eyes-review

Run it from your main session and tell it what to review: it can be a branch, a commit, a git diff, a couple of files, even a document (for example a PLAN.md). Or just invoke it without arguments and it will figure out what to review on its own and ask you to confirm the prompt for the reviewing session. Approve it, or tweak it first, and the review will start in a clean context.

The reviewing session sees the changes and their goal, and is free to check the whole codebase. What it never sees is the reasoning of the authoring session (no plan, notes, chat history, etc.). This part matters: hand it the reasoning that produced a bug, and chances are that it will overlook the bug for the same reason the authoring session did.

Findings come back to the main session: each one points at a file and describes how it actually breaks. No minor style nitpicks, no vague concerns, and "nothing found" is a valid answer by design. The reviewing session can't always distinguish a bug from an intentional choice, so the judgment is left to the main authoring session, which knows more about the task and will help you judge each finding. Then you decide what needs to be addressed.

Read the SKILL.md →

More than a code reviewer

Reviewing code is the classic case, but not the only one! You can easily point it at a document: type /fresh-eyes-review the PLAN.md against the REQUIREMENTS.md even before any code is written. The same works for a requirements doc against its original ticket, and so on.

Other skills also use /fresh-eyes-review as a building block: they pass in the changes, the goal and the review instructions themselves, and the review runs as one step of a bigger workflow (fresh context included). Any agent that can spawn sub-agents can do this.