multi-model-review
Multi-model code review and model-routed Spec-Driven Development.
Write specs with one model, implement with another, and review with a different one. This plugin turns GitHub Spec Kit artifacts (spec.md, plan.md, tasks.md) plus your git diff into portable handoffs that any CLI-capable model can consume.
The spec author or reviewer does not need to share your current session. Each handoff lives on disk as markdown, and you run the other model yourself.
Quick usage
Install as a Spec Kit extension, then initialize model routing in the target repository:
specify extension add --dev /path/to/multi-model-review
/speckit.multi-model-review.cross-review init --spec codex-5.5:xhigh@normal --spec-heavy opus-4.7:1m@max --dev sonnet-4.6@high --review codex-5.5:high@normal --subagents auto
Create or refine Spec Kit artifacts, implement the generated tasks, and export a compact review package:
/speckit.multi-model-review.spec-handoff 001-auth-rework --plan
/speckit.implement
/speckit.multi-model-review.review-package 001-auth-rework
If Headroom MCP tools are available, the package command can compress oversized
raw blocks while keeping retrieval notes in the package metadata:
/speckit.multi-model-review.review-package 001-auth-rework --headroom auto
When subagent routing is enabled, tasks can include route hints so Claude Code chooses the right specialist and model automatically:
- [ ] T001 [route:scout] Map the affected files and project rules.
- [ ] T002 [route:heavy-planner] Plan the cross-cutting API and migration changes.
- [ ] T003 [route:worker] Implement the scoped code and tests.
- [ ] T004 [route:review-checker] Run a local read-only preflight before external review.
Run the reviewer yourself, save review-report.md, then ingest accepted findings:
/speckit.multi-model-review.apply-review
Claude Code plugin installs still expose the legacy command names such as /multi-model-review:cross-review.
Why multi-model?
A model reviewing its own output often rationalizes. A different model brings:
- different priors
- different bug sensitivity
- different style and rule interpretation
Spec Kit is excellent at the single-agent flow:
/speckit.specify/speckit.plan/speckit.tasks/speckit.implement
multi-model-review is the cross-model loop around that flow:
- a spec-authoring model creates or refines
spec.md, plan.md, and tasks.md
- the implementation model builds the feature
- the builder creates a review package
- the reviewer reads that package and writes
review-report.md
- the builder ingests the report and applies fixes
Spec Kit vs. multi-model-review
This is not a replacement for Spec Kit — it is a Spec Kit extension. The honest comparison is Spec Kit on its own vs. Spec Kit with this extension installed. The question is not "which one," it is "do I want the cross-model review loop on top."
GitHub Spec Kit owns Spec-Driven Development: /speckit.constitution → /speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement, plus /speckit.analyze and /speckit.checklist for quality gates. It works with 30+ agents — but you pick one agent, and that single model drives the whole lifecycle, including any self-review. There is no built-in cross-model review step.
That single-agent design is exactly the gap this extension closes.
| Dimension | Spec Kit alone | Spec Kit + multi-model-review |
|---|
| SDD lifecycle (spec → plan → tasks → implement) | Owns it | Unchanged — still Spec Kit underneath |
| Models per feature | One agent drives everything | Spec, implementation, and review can each be a different model |
| Code review | The author model checks its own work (/speckit.analyze, /speckit.checklist are same-agent passes) | A second model reviews code it did not write |
| Handoff between agents | Tied to one live session | Portable spec.md / plan.md / tasks.md / diff packages on disk |
| Reviewer choice | n/a | Template-driven: Codex, Gemini, another Claude, Hermes, any CLI LLM |
| Review token cost | Carries the whole build session | Compact-first packages + optional Headroom compression |
| Finding hygiene | n/a | Confidence-gated, with a Context sufficiency escape hatch |
| External calls | n/a | None hidden — you run the reviewer yourself |
Why add the cross-model loop?
A model that reviews its own output tends to rationalize it: same priors, same blind spots, same rule interpretation that produced the bug in the first place. Spec Kit's /speckit.analyze and /speckit.checklist help, but they are the same agent checking its own artifacts for consistency and coverage — not an independent second opinion.
A different model brings:
