multi-model-delegation

name	multi-model-delegation
description	Multi-model design consults via PAL (kimi, glm, gemini, gpt). Use when asking other models to brainstorm a design or reconciling their split answers.
user-invocable	false
allowed-tools	Read, Glob, Grep, TodoWrite, mcp__pal__listmodels, mcp__pal__chat, mcp__pal__consensus, mcp__pal__thinkdeep
model	opus
created	"2026-07-17T00:00:00.000Z"
modified	"2026-07-28T00:00:00.000Z"
reviewed	"2026-07-28T00:00:00.000Z"

Multi-Model Delegation

Protocol for consulting other models — kimi, glm, gemini, gpt via the PAL MCP gateway (chat, consensus) — on design and judgment work, and for acting on what comes back. The core insight, which inverts the naive approach:

The value is the disagreement, not the union. Two competent models briefed identically converge on the obvious 80% — the part you'd have written anyway. Where they split is a precise pointer at the one decision that is genuinely load-bearing and underdetermined by the prompt. Resolve the split against the codebase — which usually already decided, and which the models structurally cannot see — never by picking the more confident model.

Treat delegated models as idea generators, never as authorities. Taking the majority answer, or the more confident one, launders a coin-flip into a decision that merely looks researched.

You — the orchestrating Claude session — run the whole consult: you dispatch the PAL MCP calls, collect the replies, and do the judgment steps (diff, adjudicate, synthesize) yourself in the main loop.

When to Use This Skill

Use this skill when...	Use alternative when...
Brainstorming an open design decision with foreign models (PAL chat/consensus)	Fanning out Claude subagents that do work → parallel-agent-dispatch, agent-teams
Reconciling two models' conflicting design proposals	Red-teaming a finished artifact → adversarial-review
Deciding whether a multi-model consult is worth the tokens	A lookup answers the question → PAL apilookup, official docs

The Protocol

Execute a multi-model consult in these steps:

Step 1: Resolve model IDs first

Run mcp__pal__listmodels once at the start of the consult whenever a model is named loosely ("kimi2.7", "glm5.2") — registry IDs (kimi-k2.7-code, glm-5.2) and their aliases (kimi, glm) rarely match what anyone types from memory.

Step 2: Brief every model with the same prompt

Send the identical brief, verbatim, to each model — one mcp__pal__chat call per model — and collect every reply before judging any of them. Different prompts produce divergences that are artifacts of the framing, not of the problem — and afterward you cannot tell a real design tension from a wording accident. Pass code via the absolute_file_paths parameter rather than pasting it into the prompt: it is what the parameter is for, and the pasted copy risks truncation. Attachments carry a per-model token budget that a multi-file set routinely exceeds — when it does, build one curated excerpt bundle rather than trimming per model (see below).

Step 3: Keep round one independent

Withhold model A's answer from model B. You want independent draws, not an echo. Cross-critique is a deliberate later round, never the first one.

Step 4: Diff the answers for the split

With every reply collected, compare them point by point:

• Convergence → the safe default; adopt it and move on.
• Divergence → this is the actual decision, and it is now yours — not theirs. Don't ask "which answer do I take?" Ask "what did they disagree about, and what in my codebase already decides it?"

Step 5: Adjudicate against the code, not taste

Go read the thing the decision turns on. Very often the codebase has already decided, and the models couldn't know because they can't see it. This is the step that makes the whole exercise worth its tokens.

Step 6: Graft, never adopt wholesale

Even the winning proposal carries ideas that are wrong for your repo. Graft the good parts from the runner-up; reject what doesn't fit and say why.

Canonical case (gh-board priority grading, 2026-07): kimi-k2.7-code and glm-5.2, identical briefs. They converged on the module shape and config-first weights, and both independently proposed a contribution ledger — the one idea not already in hand, and the one convergent idea worth keeping. They split on exactly one question: does the triage bucket feed the priority score, or sit above it? One minute in src/app/filter.rs settled it — build_rows already groups into bucket sections after sorting, so a bucket baseline would double-count the grouping. Both models also proposed an A–F letter grade; both were overruled — grade bands stack a second set of magic thresholds on the weights and quantize away the fine ordering the score exists to produce. The models produced the question; the repo produced the answer.

Step 7: When a claim is refuted, ask the second question

Step 5 adjudicates "is this claim true?" against the code. When the answer is no, the instinct is to discard the claim and move on. Don't — ask the second question first:

"Why couldn't the test suite answer this?"

That question survives a wrong claim. A confident, specific, false finding usually points at something real — not the defect it names, but the absence of a gate that would have settled it in seconds. The claim dies; the gap it exposed does not.

The move: add the gate that decides the question, then kill-test it by swapping in the reviewer's proposed value. If the reviewer was right, the gate goes red and you have found a real bug. If they were wrong, it goes red on their version and green on yours — converting an argument into a permanent, mechanical answer, so neither the next reviewer nor the next session can re-litigate it.

Canonical case (loractl verbosity review, 2026-07): kimi-k2.7-code claimed flag_directives emitted a loractl= tracing target matching nothing — because the package is loractl-cli — which would make the entire -v ladder inert. It was wrong: [[bin]] name = "loractl", so module_path! roots at loractl, and a live -v run had already printed INFO lines. But the claim was unfalsifiable from the suite, because the unit test asserted the directive string and never that the filter matched a real event. Fix: a spawned-binary test pair (-v must show INFO, default must not), then a kill-test swapping in the reviewer's loractl_cli= — which fails it. Wrong claim, real gap, permanent gate.

The generalization beyond model reviews: a test that asserts the shape of a value rather than the behaviour it produces cannot settle a question about that behaviour — it passes whether the wiring works or not. Those are exactly the tests an outside reviewer's wrong guess will find for you.

When It's Worth the Tokens

Worth it	Skip it
Open design decision with a wide solution space and no conventional default — scoring models, architecture splits, API shape, migration strategy	Anything with a conventional default: pick it, state it, proceed
Genuinely underdetermined trade-offs where an independent draw adds information	A lookup or doc read answers it
	Seeking agreement on a decision already made — a model asked to validate will validate; you pay for confirmation, not information

PAL Mechanics That Bite

Mechanic	Symptom	Fix
kimi-k2.7-code 400s whenever temperature is sent (OpenCode Go)	Opaque Error from provider (Console Go): Upstream request failed — names neither parameter nor constraint, so it reads as flakiness or "prompt too long"	Omit temperature for kimi; glm-5.2 accepts it fine. Prompt length, attachments, thinking_mode are all innocent. pal#67
absolute_file_paths is capped at ~60% of context headroom, and the cap varies wildly by model	The attachment set is rejected for exceeding the budget. Observed on a 262K context: gpt-5.3-codex ≈ 76,800 tokens but kimi-k2.7-code only ≈ 28,311 — one ~84K, 7-file set bounced on both	Size attachments to the smallest target model's budget. Because the identical-briefs invariant is load-bearing, one model's ceiling trims the set for all of them — build a curated excerpt bundle instead
working_directory_absolute_path must live inside PAL_WORKSPACE_ROOT	A scratchpad path outside the repo is rejected: must reside within the PAL workspace root	Work in <repo>/tmp/<consult>/, never a system temp dir
model_used is untrustworthy under concurrency	Three concurrent chat calls returned model_used values rotated across each other while provider_used stayed request-consistent	Verify independence via provider_used, and pick models on different providers — a silently same-model pair breaks the disagreement-is-the-payload logic. pal#68
Registry models get retired upstream mid-consult	A listmodels-listed id 404s ("no longer available")	Pick a same-provider fallback before dispatching, and re-send the identical brief — a reworded one breaks the invariant

Isolate a model failure with controlled probes before believing your first theory. The intuitive suspects (big prompt, file attachments) were innocent twice — a bug filed on either would have sent the maintainer down the wrong path. A two-word prompt plus the one suspect parameter settles it in one call.

The Curated Excerpt Bundle

When the load-bearing code spans more than the smallest model's attachment budget allows, do not trim per model — that silently un-identicals the briefs. Build one file and attach it to every model:

1. Write it inside the workspace: <repo>/tmp/<consult>/context-excerpts.md.
2. Include verbatim excerpts of exactly the load-bearing regions — no paraphrase; the whole point is that the models read the real code.
3. Number the sections (§1…§N), each titled with its real file path + line range, so a cited §7 resolves back to source.
4. The smallest model's budget bounds the bundle. Size the whole file under it, then attach that one path to every model.
5. Reference sections from the brief by number ("weigh §3 against §9").

Canonical case (loractl #132, 2026-07): a 7-file, ~84K-token attachment set bounced on both gpt-5.3-codex and kimi-k2.7-code. An 11-section bundle at ~21K tokens fit all three budgets, kept the briefs byte-identical, and the models cited sections accurately.

Agentic Optimizations

Context	Command
Resolve registry IDs and aliases	mcp__pal__listmodels
Independent round-one draw (repeat per model, same prompt)	mcp__pal__chat with model + absolute_file_paths; omit temperature for kimi
Attachment set exceeds the smallest model's budget	One <repo>/tmp/<consult>/context-excerpts.md bundle, attached to every model
Structured multi-model verdict with per-model stances	mcp__pal__consensus
Deep single-model dig after the split is found	mcp__pal__thinkdeep

Related

• parallel-agent-dispatch — delegating work to Claude subagents: those are delegates producing output; this skill's models are second opinions producing judgment
• agent-teams — implicit-team / SendMessage mechanics for Claude teammates
• adversarial-review — inverted-objective second pass on a finished artifact, by an isolated Claude reviewer
• verify-before-plan — the same adjudicate-against-reality instinct, applied to orchestrator premises before a dispatch