cross-model-review

Metadata

name: cross-model-review
version: 2.0.0
description: >
  Adversarial plan review using two different AI models.
  v2: Alternating mode — models swap writer/reviewer each round.
  Fully autonomous loop — no human input between rounds.
  Use when: building features touching auth/payments/data models,
  plans that will take >1hr to implement.
  NOT for: simple one-file fixes, research tasks, quick scripts.
triggers:
  - "review this plan"
  - "cross review"
  - "challenge this"
  - "is this plan solid?"
  - "adversarial review"

---

When to Activate

Activate this skill when the user:

• - Says any trigger phrase above
• Shares a plan and asks for adversarial/second-opinion review
• Asks you to "sanity check" a multi-step implementation plan

Do NOT activate for: simple fixes, one-liners, pure research tasks.

---

Modes

Static Mode (v1 — backward compatible)

Fixed roles: planner always writes, reviewer always reviews. Requires human to trigger each round.

Alternating Mode (v2 — recommended)

Models swap roles each round. Fully autonomous — no human input between rounds.

Flow:

• - Round 1: Model A writes the plan. Model B reviews.
• Round 2: Model B rewrites (based on its own review). Model A reviews.
• Round 3: Model A rewrites (based on its own review). Model B reviews.
• ...continues alternating until both agree (reviewer says APPROVED) or max rounds hit.

Why this works:

• - Each model must implement its own critique — can't nitpick without owning the fix
• The other model catches over-engineering or proportionality issues
• Natural convergence: each round addresses the other's concerns

---

Autonomous Orchestration (Alternating Mode)

You (the main agent) run this loop. It's fully autonomous after kickoff.

Step 1 — Save the plan and init

CODEBLOCK1

Captures workspace path from stdout.

Step 2 — The autonomous loop

CODEBLOCK2

Step 3 — Finalize

When the loop exits with APPROVED:
CODEBLOCK3

Present: rounds taken, issues found/resolved, rubric scores, plan-final.md location.

---

CLI Reference

CODEBLOCK4

---

Detailed Orchestration (for agent implementation)

Spawning reviewers

CODEBLOCK5

System instruction for reviewer: "You are a senior engineering reviewer. Output ONLY valid JSON matching the schema. No tool calls. No markdown fences. No preamble."

Spawning writers

CODEBLOCK6

System instruction for writer: none needed — the prompt is self-contained.

Error handling

• - Reviewer timeout/failure: retry once, then ask user
• Writer timeout/failure: retry once, then ask user
• Parse error on review JSON: re-prompt reviewer once with "Your response was not valid JSON"
• Max rounds hit: present status to user, ask for override or manual fix

Convergence

The loop converges when the reviewer says APPROVED with no open CRITICAL/HIGH blockers. The script enforces this — if reviewer says APPROVED but blockers remain, it overrides to REVISE.

---

Static Mode (v1 — backward compatible)

For static mode, the original orchestration from v1 still works:

Step 1 — Init

CODEBLOCK7

Step 2 — Manual loop

For each round: build reviewer prompt from template, spawn reviewer, parse-round, revise plan yourself, continue.

Step 3 — Finalize

Same as alternating mode.

---

Integration with coding-agent

Before dispatching any plan to coding-agent that:

• - Touches auth, payments, or data models
• Has 3+ implementation steps
• The user hasn't already reviewed adversarially

Run cross-model-review first. Only proceed if exit code 0.

---

Notes

• - Workspace persists in tasks/reviews/ — referenceable later
• INLINECODE1 tracks full lifecycle of all issues
• INLINECODE2 stores mode, models, current round, verdict, needsRevision flag
• INLINECODE3 is the state machine — always call it to determine what to do
• Dedup warnings help catch semantic drift across rounds
• Models must be from different provider families (cross-provider enforcement)
• INLINECODE4 is injected into reviewer prompts for calibration