Crossreview

Crossreview: independent reviewers, one orchestrator

One brief is written, every reviewer gets that brief and nothing else, they all answer, and then the orchestrator alone decides: which findings are real, which matter, what to fix now and what not to fix. The reviewers advise; the last word is the orchestrator's: the subagent you hand the run to in step 3, or you. Their value is in the disagreement of different models, so pick reviewers from different vendors.

Three rules hold for the whole run:

1. Reviewers are blind to each other. A reviewer never sees another reviewer's answer: not in its brief, not in a later round, not as a summary. Internal reviewers (your own subagents) included.
2. Every reviewer gets to answer. Wait until each one has answered or ended (failed, timed out). Retry the ones that failed for a passing reason before you write the report. Stop one early only when the user says so.
3. You decide, not the majority. One reviewer with evidence outweighs four without it. Your verdict may differ from every reviewer's.

<skill> below is the directory holding this SKILL.md; agents usually say where it is when they load a skill (Claude Code's "Base directory", Coddy's "Skill directory"). If yours did not, take the first of these that holds scripts/crossreview.py, and do not search the whole disk: ${CODDY_HOME:-~/.coddy}/skills/crossreview, then crossreview under ~/.claude/skills, ~/.codex/skills, ~/.cursor/skills, ~/.agents/skills, ~/.config/opencode/skills, ~/.config/devin/skills, and under the workspace's .claude/skills, .agents/skills, .cursor/skills, .opencode/skills, .coddy/skills.

The helper is python3 <skill>/scripts/crossreview.py (py -3 or python on Windows), standard library only, the same on Linux, macOS and Windows; every subcommand has --help. Without Python, see the last section.

Who you are. Every helper command that reads or writes a roster takes --host <you>: claude (Claude Code), codex, coddy, cursor, opencode, devin, gemini, qwen, kimi, or your own name. The rosters are yours, kept where you keep your settings: the global one in your home folder (~/.claude/crossreview.json, ${CODDY_HOME:-~/.coddy}/crossreview.json, ${CODEX_HOME:-~/.codex}/..., ~/.cursor/...), the local one in your folder of the project (.claude/crossreview.json, .coddy/..., .codex/..., .cursor/...). An agent not on the list uses ~/.agents and .agents. Claude Code is recognised without the flag.

Requirements. A shell and permission to write files: in a read-only mode (plan, ask) say so and stop. Reviewers call their model APIs and write their own session files, so a sandbox that blocks the network or writes outside the workspace (Codex's default) has to let the helper's commands out, or every reviewer fails.

Never recurse. If CROSSREVIEW_DEPTH is set in your environment, you are a reviewer: answer the brief directly and do not start another crossreview.

1. Reviewers

Reviewers named in the request ("crossreview with cursor auto and coddy on codex/gpt-5.6-sol") are a one-off list: pass each as --reviewer agent:model to the run and leave the roster alone.

Otherwise run crossreview.py roster --host <you>: it takes your local roster of this project when there is one, else your global one, and you act on its exit code:

• 0: use it. Relay its warnings (a brief passed as an argument breaks past 128 KB) and offer crossreview.py init --host <you> --scope <the same> --import <path> --refresh --force to move the entries to the current templates.
• 4: the local roster is not approved: it may have come with the clone, or it changed since, and it would run the commands it prints. Show them to the user and ask; only after a clear yes run the crossreview.py trust ... line it printed. On a no, use --scope global from then on.
• 2: no roster. Set one up.

Setup, also whenever the user invokes /crossreview:setup, even if a roster exists:

1. crossreview.py detect prints one line per installed reviewer CLI. Offer only those.
2. Ask which agents to use, multiple choice: with your question tool if you have one, otherwise in plain text, then end the turn and wait. Never choose for the user.
3. For each chosen agent run crossreview.py models <agent> and offer the ids it prints (multiple choice); when it prints none, ask for the id as free text. Each (agent, model) pair is one reviewer.
4. Ask where to keep the roster: local, for this project only, in your folder of it (commit the file to give the team the same reviewers; each teammate approves it once), or global, for all of your projects, in your home folder.
5. crossreview.py init --host <you> --scope local|global <agent:model>... writes it (--force over an existing one, --add to extend it, --import <file> to start from the reviewers another agent already has). --min-reviewers N raises the quorum, --timeout S the time each reviewer gets. A local roster written this way counts as approved.
6. crossreview.py probe --host <you> sends every reviewer a one-word brief. Report each failure with the reason it gives (not signed in, usage limit, unknown model) and offer to drop or fix the entry.

An internal reviewer is a subagent of a host agent on another model, written internal/<host>:<model> (internal/claude:sonnet, internal/coddy:devin/swe-2). Only the host it names runs it, read-only; other hosts skip it.

2. Brief

Take the scope from the request: the uncommitted work by default, or a branch against its base, a commit range, the staged changes, whole files, a plan or a document.

crossreview.py brief --out <tmp>/brief.md --intent "<what the change is meant to do>" \
    [--base main | --range A..B | --staged | --files F... | --doc PLAN.md] [--exclude PATHSPEC...]

• Write --intent from the conversation: a reviewer judges a change by what it was meant to do.
• The brief carries the whole diff, and its first line forbids tools: reviewers answer from the brief alone, which is fast and keeps them away from your files. When correctness depends on code outside the diff, write the brief with --tools read and give run a --cwd: a detached worktree (git worktree add --detach), never the live checkout.
• Leave out lockfiles, generated code and snapshots with --exclude. Past 150 KB split the review by layer (backend, frontend, tests): small local models stall on long briefs.
• --notes-file adds your own notes for every reviewer alike: facts about the code, decisions you already took in an earlier round. Write them yourself; never paste or paraphrase a reviewer's answer and never say who raised what.