Discussion partners

The panel is always all four

Invoking discussion-partners means firing all four legs — codex + gemini + two claude legs (fable and opus) — on the same prompt. A panel is never a subset. Want a single provider? Invoke that provider's skill (codex / gemini / claude) directly instead. Running a reduced panel is allowed only when the user explicitly OKs it (see Preflight), and the missing leg must be named in the synthesis so the gap is visible.

Panel roster

Versioned model names live in each provider's skill — change them there. This file names no versioned models; the two claude legs are distinguished by the Agent tool's stable tier aliases (fable, opus), which survive version bumps. Pointers flow one direction only (discussion-partners → provider skills), so a default bump touches exactly one file, and a new provider is a new skill plus a row here.

Leg	Strengths (incl. search)	Current model & config
codex (OpenAI)	Hard math, novel algorithms, multi-file tracing, deep correctness. Good web search over a non-Google, non-Claude index — a genuinely different read.	codex skill
gemini (Google · agy)	Fast, broad surveys, big-context dumps. Exceptionally good search — queries Google's index directly, the widest web reach of the panel.	gemini skill
claude · fable (Anthropic · Agent tool)	The global Claude read: open-ended problems, design/taste, prose, adversarial self-review — best when the framing itself is in question. WebSearch — a third, different index.	claude skill, model fable
claude · opus (Anthropic · Agent tool)	The local Claude read: more detail-oriented — works hard through well-defined but difficult problems. Catches line-level issues fable's big-picture pass skims. Same WebSearch index as fable.	claude skill, model opus

Each panelist should use its own native search fully: three different indexes (Google-direct, OpenAI's, Anthropic's WebSearch shared by both claude legs) triangulate coverage no single model reaches.

The two claude legs are family, not independents. They share training lineage and blind spots. In synthesis, fable+opus agreement is weaker evidence than any cross-provider agreement — weight codex-or-gemini concurrence above intra-Claude consensus.

Preflight — confirm the panel is real before fanning out

A silently-degraded panel is worse than no panel: an empty or errored leg looks like a completed review while a whole perspective is missing. Before firing, run each external provider's liveness probe — the exact commands live in the codex and gemini skills' "Verify installed" sections (codex's probe pins its model, so access failures surface before the panel rather than mid-run; the two claude legs run in-session via the Agent tool and need no probe).

Stop and flag to the user (don't proceed with a missing leg) if a probe fails — each provider skill's Troubleshooting section names the failure modes and fixes (codex: usage limits, login, CLI-version walls; gemini: quota tiers, wrong account identity, TUI model selection).

Proceeding with a reduced panel is allowed only if the user says so — and name the missing leg in the synthesis so the gap is visible, never absorbed.

Workflow

1. Timestamp: ts=$(date +%Y%m%d_%H%M%S)_$$.

2. Write ONE shared prompt at ~/claude/scratch/prompt_${ts}.md:

   • The reader's role, first line — "You are one panelist on a four-model panel run by the caller. Don't orchestrate or launch anything; your own review is the deliverable." Without it, an agentic leg that reads "reviewed by a panel" may take the orchestrator seat — codex has done exactly this (found these skills in a mounted repo, tried to launch the other legs, hit its read-only sandbox, and returned a refusal instead of a review).
   • Why — the goal, what kind of answer is useful (critique / review / alternatives / sanity check).
   • Current state — relevant code inline or by file path, error traces, constraints, what was tried. Give them what they need to solve from where you are now. Skip the history of how you got here — it leads the witness.
   • The question — specific and framed on purpose.

   Default: same prompt to all four. For genuinely split assignments, add inline directives ("codex: focus on module A. fable: focus on module B."). The sub-skills' standalone examples use provider-suffixed filenames (prompt_codex_<ts>.md, etc.) — that's the solo convention. From this orchestrator, pass the single shared prompt_${ts}.md instead.

3. Fire all four in parallel in one assistant message. Set run_in_background: true on each. The exact CLI syntax lives in each sub-skill's "Send a prompt from a file" section — pass each the shared prompt path:

   • codex — via Bash
   • gemini — via Bash
   • claude — via the Agent tool, twice: one call with model: "fable", one with model: "opus", distinct descriptions ("Discussion partner — Claude fable" / "— Claude opus")

   Four tool calls, one shared prompt file, one assistant message.

4. Wait for all four. Grade each report as it lands — agree or push back per finding — but synthesize and cut only after every leg arrives. Remember the family rule from the roster: cross-provider agreement outweighs fable+opus agreement.

A leg that dies mid-run is a preflight failure that arrived late. An errored, empty, or timed-out leg gets one retry — applying the provider skill's named fix for that failure mode, not a verbatim re-run (a deterministic failure fails identically; e.g. gemini's headless permission denial needs a reads-only instruction added to the prompt, per its Troubleshooting). Still down, the preflight rule applies unchanged — stop and flag, synthesize a reduced panel only with the user's explicit OK (or a calling skill's documented standing policy), and name the missing leg in the synthesis, never absorb it. "Asked for four, silently got one" is the failure mode this exists to prevent.

Prompting

• Start with why. Goals and assignments, not procedures. Let sub-agents pick the how.
• Review state, not deltas. For code or document reviews, the complete current artifact is the subject; a "review the latest changes" framing anchors panelists on the diff and misses defects in the unchanged whole. Include the diff as context if useful, never as the primary subject.
• For a PR, the PR body is the claims section. Point panelists at it (gh pr view <n> --json body) and have them verify the branch against it. Never paraphrase the claims into the prompt — a hand-written copy goes stale as the PR evolves, and panelists grading a stale claims list produce false findings. Update the body before each panel round so it describes the branch's current state — what it does now, not how it got there: no round-by-round history, no "since last review" accretions, no rejected-alternatives narrative.
• Don't lead the witness. Present evidence and the question — not a hypothesis to validate.
• Give them permission to push back. LGTM is a valid answer. So is "I don't understand the assignment", "this premise looks contradictory — reframe before I review", or surfacing surprises that should change the framing. Encourage this rather than fabricated findings.
• Be direct, skip praise, lead with strongest objections — calibrated honesty, not manufactured concerns.

For per-path framing in genuinely split assignments, consult the strengths section in each sub-skill (codex / gemini / claude).