openclaw - 💡(How to fix) Fix RFC: `@openclaw/skill-panel-ask` — broadcast a single intent across multiple AI voices in parallel with cross-family discipline [1 comments, 2 participants]

OpenClaw today is one provider at a time. Most multi-agent frameworks treat the model layer the same way. But the moment a user has multiple subscriptions (Anthropic Max, ChatGPT Plus, Google AI Pro, Perplexity Pro, xAI), they have a panel — independent priors, different RLHF reward shapes, different refusal policies. The panel surfaces real disagreement before it becomes a one-voice failure mode. It also gives outage resilience: when any one provider goes down, the others still answer.

I've been running this pattern in production on a personal openclaw fork for weeks (15 voices across 6 families, with both raw + synthesize modes). I'd like to contribute it upstream as @openclaw/skill-panel-ask.

What it does

Registers a panel_ask agent tool. Input:

{
  "tool": "panel_ask",
  "args": {
    "prompt": "...",
    "voices": ["claude-cli", "chatgpt-web", "gemini-cli", "grok-web"],
    "mode": "synthesize"
  }
}

The skill:

1. Dispatches the prompt to every voice in parallel through that voice's own working surface (CLI, web Chrome, native Mac app, or local Ollama).
2. Each voice writes a reply artifact to disk: <Label>-<Voice>-<Date>.md.
3. If mode: "synthesize", folds the panel into one consolidated answer with the hard rule that the synthesizer voice cannot share family with the dominant contributor. (This is enforced in code via selectSynthesizer(), not as a configuration guideline.)

Cross-family discipline

If three Anthropic voices reply and Anthropic is also the synthesizer, the synthesis is just one model nodding at itself. The skill rejects that configuration at run time.

Scaffold

Already scaffolded as extensions/skill-panel-ask/ in my fork. 13 files, 14/14 tests pass, oxfmt clean, typecheck clean. First iteration delegates dispatch to a battle-tested .mjs script via subprocess; Stage 3 follow-on lifts dispatch into TS and removes the subprocess hop. Voice ids stay stable; PanelAskInput/PanelAskOutput don't change.

Happy to send a PR if there's interest. Would appreciate guidance on:

• Should this be a first-class openclaw skill (openclaw skills run ...) or a tool plugin (tool: panel_ask)?
• Naming: @openclaw/skill-panel-ask or @openclaw/panel-ask?