coordinating-multi-model-work

Contents

• Coordinating Multi-Model Work
  • Overview
  • Core Instructions
  • The Two Rules
  • Checkpoint Workflow
  • Reference Files

---

Coordinating Multi-Model Work

Overview

Claude is the orchestrator — it routes tasks, coordinates models, and integrates results but never writes implementation code.

Use this module to route implementation to the right external model:

• Codex (mcp__codex__codex) — backend: APIs, databases, algorithms, server-side logic
• Gemini (mcp__gemini__gemini) — frontend: UI, components, styles, interactions
• Cursor (mcp__cursor__cursor) — DevOps: CI/CD, shell scripts, Dockerfiles, infrastructure, repo tooling

This module is intentionally minimal: it provides a small workflow and pushes details into reference files.

For review chain details, see coordinating-multi-model-work/review-chain.md.

Core Instructions

You must execute the steps below:

1 After forming an initial analysis of the user request, share the request and your initial thinking with the appropriate external model (Codex/Gemini/Cursor based on routing) and ask them to improve the requirement analysis and implementation plan.

2 Before implementing any concrete coding task, route to the appropriate external model for implementation. Claude does NOT write code — all coding goes through CODEX, GEMINI, or CURSOR.

3 After the external model completes implementation, obtain Opus review per coordinating-multi-model-work/review-chain.md.

4 All external models provide references and implementations. You must think independently and question their answers. Blind trust is worse than no trust; your joint mission is to converge on a unified, comprehensive, precise result.

The Two Rules

1. Main rule (Fail-Closed Gate): If you decide Routing != CLAUDE, you MUST obtain external output, or STOP in BLOCKED. Since Claude never implements code, all coding tasks MUST go external.

2. Early exposure: If you decide Routing != CLAUDE, run the external call before doing real work (writing code, generating tests, or producing final conclusions).

Checkpoint Workflow

At skill checkpoints (CP1/CP2/CP3):

1. Decide routing using coordinating-multi-model-work/routing-decision.md
2. If Routing != CLAUDE, apply coordinating-multi-model-work/GATE.md immediately (evidence or BLOCKED)
3. Continue only after evidence is recorded

Token Optimization (Response Protocol)

All external model prompts include a Response Protocol that prevents token waste (thinking narration, context repetition, unstructured output). The protocol is stored in Serena shared memory (global/response_protocol) and read by all agents via the shared Serena HTTP instance.

Every PROMPT to an external model MUST end with:

## Response Protocol
FIRST: Read Serena memory 'global/response_protocol' for full format rules.
FALLBACK: You respond to an orchestrator agent, NOT a human. NO thinking narration, NO restating context, NO full file rewrites. Output: ## ANALYSIS (≤200 words) → ## DIFF (changed hunks only) → ## ISSUES (≤5) → ## VERDICT (one sentence).

See coordinating-multi-model-work/INTEGRATION.md for complete templates.

Reference Files

• Checkpoint logic: coordinating-multi-model-work/checkpoints.md
• Routing framework (semantic): coordinating-multi-model-work/routing-decision.md
• Fail-closed gate + evidence format: coordinating-multi-model-work/GATE.md
• Invocation templates + response protocol: coordinating-multi-model-work/INTEGRATION.md
• Review chain (canonical): coordinating-multi-model-work/review-chain.md
• Cross-validation mechanism: coordinating-multi-model-work/cross-validation.md