The Dual Reviewer: Steal This Skill

System · Free skill

The Dual Reviewer

One agent cannot properly check its own work. This skill runs a second one the moment the first one finishes, a different model with no shared context, so it catches the gaps the first agent wrote and never saw. Setup takes about five minutes.

The problem: an agent grading its own homework

Your coding agent finishes a task. It tells you the work is done. You ship it. A week later something breaks on an input nobody tested.

Here is why that keeps happening. The agent that wrote the code is the worst reviewer of it. It already decided the approach was right. It carries every assumption it made while building, so it reads its own output through the same blind spots that produced the bug. Ask it to review its work and it mostly agrees with itself.

A team solves this with a second pair of eyes. One person writes, another checks, and the reviewer was not in the room for the first decision. You can give your agents the same arrangement. That is the whole idea here.

How it works

Two agents, one rule between them.

The first agent does the build. When it finishes, a second agent starts cold. Different model. No memory of the first conversation. All it gets is the task goal, the list of files that changed, and an instruction to find what is wrong.

Because the reviewer never saw the reasoning, it does not inherit the blind spots. Two models trained differently tend to miss different things, so what the first one glossed over, the second one flags. You get two independent reads on one job at roughly the cost of one. Nothing reaches you as "done" until the review has run.

The skill

Copy the whole block. Drop it into your agent as a skill file, or paste it into a fresh chat and tell the agent to follow it. It works with Claude, with Codex, or with one of each.

---
name: dual-reviewer
description: After your first agent completes a build or task, invoke this skill to run a second agent, a different model with no shared conversation, to independently audit the output for gaps, missed edge cases, and errors before you see the result.
---

# Dual Reviewer

> What this does, in one line: it automatically runs a second, independent agent on your latest build to catch what the first agent missed. Different model, no shared context, a genuine second opinion.

## Before you start (fill this in)

This is the only thing you provide. Everything else is automatic.

| Fill in | What it is | Example |
|---|---|---|
| REVIEWER_MODEL | The model the second agent uses. Pick something different from your main agent for genuinely independent eyes. | claude-opus-4-8 |

## What you need installed

- Claude Code, or any agent that supports a subagent tool for spawning a fresh context
- Optional: Codex CLI (npm install -g @openai/codex) if you want Codex as the second reviewer instead of a second Claude model

## How to use it

1. Put this SKILL.md where your agent looks for skills. In Claude Code, that is a skills/dual-reviewer/ folder. Or paste this whole file into a new chat and say "follow this skill".
2. Fill in the REVIEWER_MODEL above.
3. After any build or task completes, tell your agent: "Run the dual reviewer on what you just built."

## The workflow (what the agent does)

1. Collect the work summary. Gather the task goal, the files changed or created, and any key decisions. Keep it to one concise block. This is all the second agent gets.

2. Spawn the second agent with zero prior context. Using the subagent tool, or Codex CLI with --model REVIEWER_MODEL, launch a fresh agent with ONLY this prompt:

   ```
   You are a code reviewer with no knowledge of how this was built.

   Task that was completed: [TASK_GOAL]
   Files changed: [FILE_LIST]

   Review these files for:
   - Correctness: does the implementation match the stated goal?
   - Missed edge cases: what inputs or scenarios would break this?
   - Security: any injections, leaked secrets, or unsafe operations?
   - Simplicity: is anything overcomplicated that could break silently?

   Be specific. List each finding with the file and line number where relevant.
   If nothing is wrong, say so explicitly.
   ```

3. Read the reviewer's findings. The second agent returns them without any of the assumptions the first agent baked in. Different model, different blind spots.

4. Surface to you before sign-off. Present the findings clearly. You decide which to act on. Nothing ships until this step completes.

## If something goes wrong

- "Agent tool not available": you are on a model that cannot spawn sub-agents. Use Codex CLI as the second reviewer instead: codex --model REVIEWER_MODEL "Review these files: [FILE_LIST]"
- "Review found nothing": that is a valid result. The second agent ran, and zero findings means it passed.
- "Review is too generic": tighten the prompt in step 2 with the actual function names and expected behaviors. Specific context yields specific findings.
- "Files too large for one context": review the changed files in batches of three to five. Run the skill multiple times, one batch at a time.

How to use it

Save the file where your agent reads skills, then fill in the one model name at the top. Pick a reviewer that is different from your builder, because two copies of the same model share too many blind spots. After any build, say "run the dual reviewer on what you just built" and read what comes back.

What you get back

1. A findings list, not a rubber stamp. The reviewer reports what is wrong with file and line references, or it states plainly that it found nothing.

2. A correctness check. Does the code do what the task asked, or does it merely run without crashing.

3. The edge cases the builder skipped. Inputs and states that were never tested, named before a customer finds them.

4. A security pass. Leaked secrets, unsafe operations, the kind of thing that is cheap to fix now and expensive after launch.

5. A simplicity flag. Anything overbuilt enough to break quietly later gets called out so you can cut it.

The limits you should know

This is a second opinion, not a guarantee. A reviewer can still miss things, and two agents agreeing does not make code correct. Treat the output as a strong first filter, not a sign-off you stop reading.

It also does not remove your judgment. The reviewer hands you findings; you decide which ones matter, and some will be false alarms. That is the job working as intended, not a fault.

Two practical limits. If your changed files are large, feed them in batches of three to five, or the reviewer runs out of room and the review turns shallow. And if the findings come back vague, the fix is almost always your prompt: name the actual functions and the behavior you expected, and the next pass gets specific.

When not to bother: a one-line copy change or a throwaway script does not need a second agent. Save it for the builds where a silent bug costs you real time.

If you do one thing this week

Install it on your next real build and read the first review it produces. Not the trivial change. The one where you were fairly sure the agent got it right. That run tells you whether a second set of eyes was worth five minutes of setup, and most of the time it pays for itself on the first finding.