cross-review

name	cross-review
description	Delegate code review to a subagent running a specific model. Use ONLY when user explicitly names a model to review changes ("review with opus", "use sonnet to review", "review with gemini"). The root agent reconstructs changes from conversation history and spawns a subagent with the code-review skill using the specified model. Do NOT use for general code review (use code-review skill instead), for reviewing PRs from git history, or when no model is specified by the user.
triggers	["review with","review using","review via","cross review","different model review"]
negatives	["comprehensive review","zen review","simple review","code review"]
license	MIT
compatibility	opencode
metadata	{"workflow":"review","audience":"developers","version":"1.0.0"}

Reconstruct what you changed during this conversation, then delegate the actual review to a single subagent running the code-review skill with a user-specified model.

IMPORTANT: Steps 1-2 run in the current agent (the master). Only Step 3 spawns a subagent.

Workflow

Step 1: Parse the user request

Extract:

• Model: The model ID from user's request. Validate against available models.
• Review instructions: Any text after "Review instructions:" — pass verbatim.
• Change scope: What should be reviewed. Default: all changes in this conversation.

Step 2: Gather context from your own changes

Reconstruct the diff from conversation history:

1. Compose a unified diff of all changes (Edit, Write, Bash, etc.). Group by file.

   • If no changes: Inform user and stop.

2. Read final state of changed files for surrounding context.

3. Check related context:

   • Test files related to changed files (skip node_modules, .git, dist, build)
   • Config changes that affect behavior
   • Related type definitions or interfaces

Do NOT show gathered context to user. Use only for the subagent.

Step 3: Spawn the review subagent

spawn_subagent:
  skill: "code-review"
  model: <model from user request>
  prompt: |
    Review the changes below using "code-review" skill.

    CONSTRAINTS:
    - Read-only review. Do NOT edit files.
    - All context is provided below. Read files only if clearly incomplete.
    - Review independently and objectively.

    ## Review Instructions
    {user's review instructions, verbatim}

    ## Changes
    {reconstructed diff, grouped by file}

    ## Additional Context
    {links to related files, tests, type definitions, requirements}

Step 4: Relay the result — READ-ONLY, NO ACTIONS

CRITICAL: Output the subagent's review AS-IS. Do NOT:

• Summarize, rephrase, reorder, or filter
• Fix, improve, or refactor based on findings
• Add your own commentary or caveats

One-line model attribution is acceptable. You may offer to implement recommendations, but let the user decide.

Model Mapping

When user says "review with [model name]", map to a valid model ID:

User says	Model ID
opus, claude opus	claude-3-opus
sonnet, claude sonnet	claude-3.5-sonnet
gpt-4, gpt4	gpt-4
gpt-4o	gpt-4o
gemini	gemini-2.0-flash
deepseek	deepseek-chat

If the model name is unrecognized, ask for the exact model ID.

Error Handling

• Subagent fails or times out: Inform user. Suggest retry or different model.
• No changes in conversation: Inform user and stop.
• Incomplete review: Relay what was returned. Note it may be incomplete.
• Model not available: Offer alternative from the mapping table.
• User requests unknown model: Map fuzzy names to model IDs using the mapping table. If no match, ask user to provide the exact model ID string.
• Subagent returns malformed output: The review subagent may return text instead of structured findings. Relay what was returned and note the format deviation.
• Diff context exceeds subagent limits: For very large changesets, split the diff by file or module and run multiple sequential subagent reviews. Inform user you are splitting the review.
• Network or infrastructure failure during spawn: Retry once with the same configuration. If it fails again, offer to switch to a different model or perform the review inline.
• Subagent produces factually incorrect findings: Relay findings as-is but append a note that some claims could not be verified against the codebase. Do not filter or censor.

Anti-Patterns

Pattern	Problem	Fix
Using cross-review for general PR review	User did not name a model. cross-review is for explicit model-named delegation only.	Use the standard code-review skill instead.
Summarizing or filtering subagent output	The user requested an independent review. Any distortion defeats the purpose.	Relay output verbatim. Add only a 1-line model attribution.
Acting on findings without user approval	The master agent is read-only in this workflow. Fixing issues automatically breaks the delegation contract.	Offer to implement recommendations but wait for user to decide.
Skipping context gathering (Step 2)	Sending only the diff without file context produces shallow reviews that miss type errors and behavioral changes.	Always read final file state and related test/config files before spawning the subagent.
Delegating to the same model the user is already talking to	If user says "review with sonnet" and master agent IS sonnet, this is circular.	Use a different model than the one running the master agent.
Requesting review of unchanged code	cross-review only works on changes made in the current conversation.	If the user wants PR review from git, use the code-review skill directly.

Model Comparison Methodology

When to use which model

Model	Strengths	Best for
Claude Opus 4	Deep reasoning, security analysis, architectural review	Complex refactors, auth code
GPT-5 Codex	Code generation patterns, syntax accuracy	Implementation review, template checking
Gemini 2.5 Pro	Multi-modal, context window size	Large PRs (200+ files), full-repo context
DeepSeek V4	Fast, cost-effective, strong at bug detection	Routine PRs, quick checks

Confidence Scoring

Assign confidence (0.0-1.0) to each finding:

confidence = (models_agreeing / total_models) * evidence_score

evidence_score:
  1.0 = exact line + code excerpt proves the bug
  0.7 = logic analysis suggests probable issue
  0.4 = speculative (pattern matching without code walk)
  0.1 = style preference

Findings with confidence < 0.5 should be:

• Marked as "suggestion" not "finding"
• Never block a merge
• Phrased as questions: "Did you consider...?"

Result Merging Strategy

1. Group by file + line range (+-5 lines)
2. If all 3 models agree: high confidence, use as primary finding
3. If 2 of 3 agree: medium confidence, note the dissenting model's view in details
4. If 1 of 3: low confidence, verify against code manually before including
5. Merge descriptions: take the most specific one, append key insights from others
6. Remove duplicates: same finding described differently -> keep clearest description

Handling Conflicts

When models disagree:

• Don't default to majority -- investigate the code yourself
• The dissenting model may have caught something the others missed
• Present both views: "Claude suggests X, Gemini suggests Y"
• Let the human reviewer decide

Checklist

• Valid model name passed (not an alias or unsupported ID)
• Diff or context reconstructed accurately from conversation history
• Subagent has the code-review skill loaded
• Review result captured from subagent output (not assumed)
• Fallback model specified if primary model is unavailable

Sources

• MCP Protocol specification (modelcontextprotocol.io) — subprocess agent spawning and message passing
• OpenAI API model list documentation (platform.openai.com/docs/models) — supported model IDs and capabilities
• Anthropic Claude model documentation (docs.anthropic.com/en/docs/about-claude/models) — model IDs and feature comparison
• Google Gemini API model documentation (ai.google.dev/models/gemini) — Gemini model identifiers and rate limits
• DeepSeek API documentation (platform.deepseek.com/api-docs) — model IDs and context window limits
• Conventional Comments specification (conventionalcomments.org) — structured review comment formatting
• "Software Engineering at Google" by Titus Winters, Tom Manshreck, Hyrum Wright (O'Reilly, 2020) — code review best practices at scale