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.
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. It also looks for what the change forgot: when a file format, a payload or a config changes, it checks the samples, fixtures and docs that should have changed with it. 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. It doesn't leave anything behind in your project: the tests it runs keep their reports out of it, and if it still creates a file, that file is removed before the findings come back (any file it changed is pointed out to you).
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.
self-review
Run /self-review on your branch before you ask anyone to review it. A sub-agent with a clean context checks the changes the way a maintainer would: would anything here block the merge? It also checks them against your project's own docs (contributing guide, code style) and looks for leftovers like debug prints and stray TODOs. It gets the branch and a short summary of the goal, not the plan or notes behind it.
Then you go through the findings one at a time, each with a recommended answer: fix it, dismiss it with a reason a maintainer can follow, defer it to a follow-up, or just discuss it. A fix gets a new round that checks the fix and what it touches, not the whole branch again.
It all ends up in a short SELF-REVIEW.md you paste into the PR, so whoever reviews your PR sees at a glance that the work was checked. Nothing is committed or pushed for you, and the PR description itself is a job for /handover. Someone else's PR? That is what /maintainer-review is for.
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 use /fresh-eyes-review as a building block. /self-review runs it on your branch before you open a PR, /harden-artifact runs it on a REQUIREMENTS.md or PLAN.md against its ticket, and /maintainer-review uses it to double check its own findings on someone else's PR, even when it found nothing. They pass in the changes, the goal and the review instructions themselves, so the review starts without asking you to confirm the prompt. Works with any agent that can spawn sub-agents. If yours can't, the review runs in the same session and the result is flagged as weaker.