eliasoulkadi/shokunin/cross-review

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.

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

1. 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:

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

Model Comparison Methodology

When to use which model

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