Consult panel

Consult Panel

Why this exists

A single outside model already beats reasoning in an echo chamber. A panel of three genuinely different models — different providers, different training — beats that again, because their independent agreement and independent disagreement are both information. When Codex, Grok, and OpenCode each answer the same question cold and land in the same place, that convergence is hard-won confidence, not one model repeating itself. When they split, the split points straight at the part of the problem that is genuinely under-determined — your blind spot.

This is deliberately the higher-bar sibling of consult-codex / consult-grok / consult-opencode. A panel spends roughly three times the tokens and runs three CLIs, so it earns its cost only on calls where a single opinion would not move the risk but a three-way triangulation would: a costly or irreversible architectural fork, a risky migration or diff, a plan worth stress-testing from three angles, or a tie you cannot break from the evidence alone. For an ordinary second opinion, reach for one of the single skills instead.

The one rule: blind and parallel, never a relay

All three members answer the same prompt, at the same time, with no knowledge of each other. Do not feed one model's answer into another's prompt. The moment a model sees a peer's answer it anchors to it, the panel herds toward one view, and you lose the only thing a panel is for — independent divergence. The wrapper enforces this by fanning out in parallel; keep it that way.

How to consult the panel

1. Write one self-contained prompt — the panel sees none of your conversation

This is the most important step, and it is shared across all three members, so it has to stand entirely on its own. None of the models see this chat, the files you've read, or the decision history. Put everything they need to reason into the prompt and write it to a file (avoids shell-quoting pain):

• Context — the relevant facts, code, constraints, and the options on the table. Enough to reason from, not so much that the question drowns.
• The specific question — one clear ask, with the concrete alternatives if it's a fork.
• A standing instruction to disagree if warranted — e.g. "You are an independent reviewer. Reason from the facts below and give a decisive recommendation. Do not just agree — if you disagree, say so and why." Present the context fairly and do not lead them to your conclusion — you want three real opinions, not three echoes.

Write it to a temp file, e.g. /tmp/panel-query.md.

2. Run the whole panel through the orchestrator

bash <skill-dir>/scripts/ask-panel.sh /tmp/panel-query.md

The script calls the three existing single-skill wrappers in parallel — it does not reimplement any CLI invocation, so each member keeps its own verified flags and quirks. It prints each member's answer in a clearly delimited block with its exit status. Wall-clock is roughly the slowest member, not the sum. Useful overrides (all optional):

PANEL_TIMEOUT=420 bash <skill-dir>/scripts/ask-panel.sh /tmp/panel-query.md   # per-member seconds
PANEL_MEMBERS="codex grok" bash <skill-dir>/scripts/ask-panel.sh /tmp/panel-query.md  # subset
# Per-member model overrides pass straight through to the wrappers:
CODEX_MODEL=gpt-5.5 GROK_MODEL=grok-build OPENCODE_MODEL=deepseek/deepseek-v4-flash \
  bash <skill-dir>/scripts/ask-panel.sh /tmp/panel-query.md

A member that hangs is abandoned at PANEL_TIMEOUT and the rest of the panel still returns; a member that errors is reported as failed. If at least one member answers, you have a usable (if partial) panel — say which members you actually heard from.

3. Synthesize in prose — surface convergence and divergence honestly

Read all three answers and write a prose synthesis (no fixed template). Make two things explicit every time:

• Where they converge — if all three (or the ones that answered) land on the same recommendation, say so plainly; that is the earned-confidence signal, state it as such.
• Where they diverge — name who split off and on what, and treat the split as a map to the genuinely under-determined part of the problem. Weigh the reasoning on the merits, not by vote count: a lone member with a sharp argument can be right against the other two.

Then give your own reconciled recommendation. If the panel contradicts a conclusion you'd already reached from primary evidence, don't just switch — name the conflict and say which constraint breaks the tie. Don't quietly fold the panel's answer into yours, and don't quietly ignore it. Clean up the temp prompt file when done.

Interpreting the result

• All three agree → the strongest signal you can get short of proof. State it as earned confidence; it is three independent systems, not one repeating itself.
• Two against one → not a vote to rubber-stamp. Read the lone dissent closely — it is often where the real risk lives. Decide on the argument, not the headcount.
• Three-way split → the question is genuinely under-determined or under-specified. That itself is the finding: tighten the question, surface the trade-off to the user, or gather the missing evidence rather than forcing a false consensus.
• Treat the panel as three peer reviewers, not three oracles. Any of them — and you — can be confidently wrong.

Relationship to the single consult skills

consult-panel is strictly the heavier tool. If one cross-model opinion would settle the question, use consult-codex, consult-grok, or consult-opencode directly and save the other two calls. Convene the panel only when the disagreement structure among three models is itself the thing you need — that is what the extra cost buys.

Troubleshooting

• could not find wrapper for member "X" — the orchestrator locates the sibling skills by walking up from its own directory and, failing that, the git repo root. Either install all four consult-* skills side by side, or point it explicitly with ASK_CODEX_SH / ASK_GROK_SH / ASK_OPENCODE_SH.
• A member times out — raise PANEL_TIMEOUT, or drop it for this call with PANEL_MEMBERS. A single hang never blocks the others.
• A member exits non-zero — its block shows the error output; debug it with that member's own single skill, whose SKILL.md has the per-CLI troubleshooting (trust gates, model flags, permission modes).
• All members failed — the orchestrator exits non-zero. Re-run one member through its single skill to get the underlying error message cleanly.