Many Brain One Decision

---
name: many-brain-one-decision
user-invocable: false
description: 'Run a multi-agent debate to compare options and converge on a decision.'
allowed-tools: Read, Write, Glob, Grep, Task, Bash(bun *), Bash(claude *), Bash(pi *), Bash(grok *), Bash(codex *), Bash(botctl *), Bash(command -v *), Bash(curl *), Bash(jq *)
---

# Many Brain One Decision

This Skill runs a moderated debate across multiple AI agents and converges on one decision. The host thread owns the context, creates the decision brief, assigns each debater a distinct personality, evaluates each round, eliminates weak options, and repeats until all active debaters choose the same outcome or the maximum round count is reached.

Do not invoke the `many-brain-one-task` Skill recursively. Reuse its agent/profile conventions and helper scripts, but run this decision workflow directly.

## Instructions

### Step 1: Build The Decision Brief

Gather the decision context from the current chat thread. The agents should not need to reconstruct the conversation themselves.

Create a compact brief containing:

- The exact decision question.
- Relevant background and constraints.
- Evaluation criteria for what "best" means.
- The decision mode: `fixed-choice`, `open-proposal`, or `hybrid`.
- Candidate outcomes with stable IDs, usually `A`, `B`, `C`, etc., when the user provided choices or explicitly requested multiple choice.
- The maximum debate rounds. Default to 4 when unspecified; honor explicit user limits such as "in 3 rounds or less", "one round only", or `--rounds 2`.
- Any explicit user preferences, exclusions, or required follow-up work.

Use `fixed-choice` when the user gives a closed set of options or explicitly asks for multiple choice. Preserve the user's options and do not invent new ones unless the user permits a write-in option.

Use `open-proposal` when the user provides facts, context, or a problem statement and asks to propose, design, solve, recommend, or decide what to do. Do not force a premature option list. Let each debater independently propose a solution in round 1, then have the host cluster those proposals into candidate outcomes for subsequent rounds.

Use `hybrid` when the user provides initial options but also allows alternatives. Include the user's options and add `WRITE_IN` as an explicit option for round 1.

Ask one short clarification only when criteria are truly unknowable or the decision is high-stakes enough that guessing would be harmful.

Keep a `NO_DECISION` or `NONE_OF_THE_ABOVE` option only when rejecting all candidates is a legitimate outcome.

### Step 2: Select Agents

Exact CLI flags live in sibling MBOT [reference.md](../many-brain-one-task/reference.md). Load that file for argv, not another copy of this table.

**Who** — first match wins:

1. `--profile X` → `X.md` here, else sibling `../many-brain-one-task/X.md` (agent selection only).
2. User-named agents/models; a profile fills only missing details.
3. [defaults.md](defaults.md).

**Family** — classify each resolved debater as `claude` | `grok` | `pi` | `other`:

- Opus / Sonnet / Haiku / Fable → `claude`
- `grok` / `Grok CLI` / `xAI Grok` → `grok`, unless the line says OpenCode / `colin-mbot-grok`
- `pi` / `Pi agent` → `pi`. The Pi package defaults every unnamed debater to `pi`
- GPT, GLM, Qwen, Gemini, and the rest → `other`

**Route** — depends on the *host harness*, then first working mechanism. A profile may pin a specific CLI. Both Claude Code and OpenCode are valid hosts; establish which one you are before planning. Tell them apart by your own tool surface: the Claude parent has the native `Agent` tool, the OpenCode parent has the OpenCode `task` tool and no `Agent`.

| Family | Claude Code host | OpenCode host |
|---|---|---|
| `claude` | Native Agent (`run_in_background: true`) → **botctl prompt** → `claude` CLI | `mbot-run` slot + `colin-mbot-opus` / `-sonnet` / `-fable` |
| `grok` | `grok` CLI (`grok version` once per run) → `colin-mbot-grok` | `mbot-run` slot + `colin-mbot-grok` |
| `pi` | `pi --print < prompt.md` | `pi --print < prompt.md` (only if `pi` is installed) |
| `other` | Sibling `mbot-run.ts` | `mbot-run` slot + `colin-mbot-<family>` |

Grok CLI host: native `spawn_subagent`. Pi host with `pi-fast-subagent`: its `subagent` tool.

**On an OpenCode host, keep every debater inside OpenCode.** Run all of them through `mbot-run` with a `colin-mbot-*` agent — Claude models included — rather than shelling out to `claude` / `botctl` / `grok`. One harness means one attach, one concurrency cap, one harvest path, and uniform cost accounting. Do **not** use the OpenCode `task` tool for debater slots: it skips `--out` harvest and timeout salvage. Shell out only when the profile pins a CLI, or the `colin-mbot-*` agent file is missing from `~/.opencode/agents/`. A containerised OpenCode host may not ship `grok` / `botctl` / `pi` at all — `command -v` before planning a CLI route.

Do not call `occtl` or `run-opencode.ts` from this skill.

**Launch notes:**

- Prompts and results stay under `.tmp/many-brain-one-decision/<slug>/round-N/` inside the project root.
- Debate rounds must not spawn nested agents (`--disallowed-tools Agent` / `--no-subagents` where the CLI supports it). The `colin-mbot-*` agents already set `task: deny`, so OpenCode slots need no extra flag.
- Unique `--session-id` per parallel `botctl` / Claude debater.
- Require a parseable `BEGIN_MBOD_JSON` block, or the normal schema-repair path.
- **OpenCode host:** `launch --detach` then `barrier` — a blocking launch dies with its occtl children when the 120s bash-tool timeout fires. **Claude Code host:** blocking `launch` is fine.
- OpenCode slots: one-round `plan.json`, then `mbot-run launch` / `harvest`:

```json
{
  "run_dir": ".tmp/many-brain-one-decision/<slug>/round-N",
  "project_dir": ".",
  "attach": "http://127.0.0.1:4096",
  "concurrency": 3,
  "timeout_ms": 1200000,
  "slots": [
    {
      "slot": "gpt-tech-bro",
      "planned_model": "openai/gpt-6.1-sol",
      "model": "openai/gpt-6.1-sol",
      "agent": "colin-mbot-gpt-sol",
      "variant": "high",
      "harness": "opencode",
      "prompt": "gpt-tech-bro.md",
      "out": "results/gpt-tech-bro.out"
    },
    {
      "slot": "opus-bean-counter",
      "planned_model": "anthropic/claude-opus-5-5",
      "model": "anthropic/claude-opus-5-5",
      "agent": "colin-mbot-opus",
      "variant": "high",
      "harness": "opencode",
      "prompt": "opus-bean-counter.md",
      "out": "results/opus-bean-counter.out"
    }
  ]
}
```

`mbot-run` auto-picks an agent only for GPT/OpenAI models. Every other family must set `"agent"` and `"model"` on the slot:

| Family | slot `agent` | typical slot `model` |
|---|---|---|
| Opus | `colin-mbot-opus` | `anthropic/claude-opus-5-5` |
| Sonnet | `colin-mbot-sonnet` | `anthropic/claude-sonnet-5` |
| Fable | `colin-mbot-fable` | `anthropic/claude-fable-5-1` |
| GPT | `colin-mbot-gpt-sol` | `openai/gpt-6.1-sol` |
| Grok | `colin-mbot-grok` | `xai/grok-4.7` (provider id is `xai`, not `x-ai`; the agent pins no model, so an unset slot `model` falls through to GPT) |
| GLM / Qwen / Kimi / Gemini / DeepSeek / MiMo / MiniMax | `colin-mbot-<family>` | resolve from attach `/config/providers` |

Never `--agent build` / `general`, and never omit `"variant"`. Do not use `claude-code/*` models for debater slots — that provider is the parent harness's, not a fan-out target.

```bash
bun "${CLAUDE_SKILL_DIR}/../many-brain-one-task/mbot-run.ts" launch \
  --plan .tmp/many-brain-one-decision/<slug>/round-N/plan.json
bun "${CLAUDE_SKILL_DIR}/../many-brain-one-task/mbot-run.ts" harvest \
  --run-dir .tmp/many-brain-one-decision/<slug>/round-N
```

**OpenCode server selection.** `mbot-run` reads `OPENCODE_SERVER_HOST` / `OPENCODE_SERVER_PORT` / `OPENCODE_SERVER_PASSWORD`, and already-set env wins over the plan's `"attach"`. Put the matching URL on the plan anyway so it stays in attach mode and never `--spawn`s.

Inside the **Seamus podman container** that env already points at the in-container bot serve, `127.0.0.1:4096`. Do not retarget to the operator's personal server (port `4095`, host `100.110.251.42`, hostname `seamus`) — Seamus rewrites it back and bot work must not land there. The image ships `bun`, `claude`, `codex`, `cup`, `glab`, `jq`, `occtl`, `opencode`; it does **not** ship `grok`, `botctl`, `cr`, `pi`, `gemini`, or the `agentsview` CLI, so every debater there is an OpenCode slot. `AGENTSVIEW_URL` is injected — run `mbot-run usage` without `--no-agentsview`.

### Step 3: Assign Personalities

Each active debater gets exactly one personality, and that pairing stays fixed across rounds. If the user names personalities, use those first. If there are more named personalities than selected agents, add backup agents so each named personality is represented when possible. If there are fewer personalities than agents, generate additional distinct personalities.

Default personality pool:

- `keep-it-simple-stupid`: prefers the simplest viable option; distrusts complexity and cleverness.
- `tech-bro`: favors new, high-leverage tools and strong developer experience; may overvalue hype.
- `ambitious-first-principles`: thinks from fundamentals and long-term scale; accepts risk if upside is large.
- `bean-counter`: optimizes for cost, ROI, time-to-value, and operational efficiency.
- `paranoid-security`: threat-models everything; prioritizes safety, compliance, reversibility, and correctness.
- `pragmatic-operator`: favors what can ship and be maintained by the current team.
- `user-advocate`: centers the end user, support burden, accessibility, and trust.
- `contrarian`: argues against the apparent consensus to surface hidden failure modes.

If a personality references a real person, treat it as a high-level decision-making archetype, not an impersonation. Personalities should create useful pressure and varied reasoning, not low-quality roleplay.

### Step 4: Round 1 Prompts

Launch all debaters in parallel. Round 1 is independent: do not include other agents' opinions yet.

For `fixed-choice` mode, use this prompt shape for each debater:

```markdown
## Many Brain One Decision: Round 1 of [MAX_ROUNDS]

### Decision Question
[question]

### Decision Brief
[background, constraints, criteria]

### Options
- A: [option]
- B: [option]
- C: [option]

### Your Personality
You are `[personality-name]`.

[3-5 sentences describing values, style, and blind spots]

### Instructions
Argue from your assigned personality, but keep the reasoning useful and grounded in the decision brief.

You must:

1. Pick exactly one option ID.
2. Give a concise argument for your choice.
3. Score every option from 1-10.
4. Name any options you believe should be eliminated.
5. End with the required machine-readable block.

Required final block:

BEGIN_MBOD_JSON
{
  "choice_id": "A",
  "confidence": 0.78,
  "reasoning_summary": "One sentence summary in your assigned voice.",
  "scores": {
    "A": 9,
    "B": 6,
    "C": 3
  },
  "can_accept": ["B"],
  "should_eliminate": ["C"],
  "changed": false
}
END_MBOD_JSON
```

Do not allow hedging in the structured block. The prose may discuss nuance, but `choice_id` must be one surviving option ID.

For `open-proposal` mode, use this prompt shape for each debater instead:

```markdown
## Many Brain One Decision: Round 1 of [MAX_ROUNDS]

### Problem To Solve
[question or problem statement]

### Facts And Constraints
[background, constraints, criteria]

### Your Personality
You are `[personality-name]`.

[3-5 sentences describing values, style, and blind spots]

### Instructions
Propose your own solution organically. Do not wait for the host to provide options. Your proposal should be concrete enough that another agent could argue for or against it in later rounds.

You must:

1. Propose exactly one primary solution.
2. Give the solution a short name.
3. Explain why it fits the facts and constraints.
4. Identify the biggest risk or weakness in your own proposal.
5. State what evidence would change your mind.
6. End with the required machine-readable block.

Required final block:

BEGIN_MBOD_JSON
{
  "proposal_name": "Short solution name",
  "proposal_summary": "Concrete one-sentence solution description.",
  "confidence": 0.74,
  "reasoning_summary": "One sentence summary in your assigned voice.",
  "key_tradeoffs": ["tradeoff one", "tradeoff two"],
  "biggest_risk": "The main way this could fail.",
  "would_change_mind_if": "Specific evidence or constraint that would change your recommendation.",
  "changed": false
}
END_MBOD_JSON
```

For `hybrid` mode, use the fixed-choice prompt but include `WRITE_IN` as an option. If a debater chooses `WRITE_IN`, require the same `proposal_name` and `proposal_summary` fields used by open-proposal mode.

### Step 5: Moderate Each Round

After each round, the host thread parses the outputs and creates a moderator memo.

Extract:

- Each debater's model, personality, choice or proposal, confidence, scores when present, acceptable alternatives, and elimination suggestions.
- Vote count by option.
- Average score by option.
- The strongest argument for each still-active option.
- Any agent failures or unparsable outputs.

For `open-proposal` round 1, cluster the organic proposals into 2-5 candidate outcomes before checking consensus. Merge proposals that are materially the same even if they differ in wording. Preserve important variants when they imply meaningfully different implementation choices, risk profiles, sequencing, or tradeoffs. Assign stable option IDs to the clustered outcomes.

When clustering proposals, create a candidate slate with:

- Option ID.
- Name.
- Synthesized solution summary.
- Source debaters who proposed or substantially supported it.
- Main supporting argument.
- Main risk or unresolved question.

If all debaters independently propose materially the same solution in open-proposal round 1, treat that as consensus after the host names and summarizes the shared outcome. If proposals differ, continue with the clustered candidate slate in fixed-choice style for round 2 and later.

If a response lacks valid JSON, recover the choice from prose if obvious. If it is not obvious, ask that debater once for a schema-only repair. If it still fails, mark the debater inactive for that round and continue. Replace a failed debater with a backup only in round 1; after round 1, preserve continuity unless fewer than two debaters remain.

Consensus is reached only when all active debaters choose the same option ID. Do not declare consensus merely because one option has a majority or the best average score.

Eliminate weak options only when no consensus exists and the current round is less than the configured maximum round count. Apply these rules conservatively:

- Never eliminate the current vote leader.
- Never eliminate every option; keep at least one active option.
- Prefer keeping at least two options until a final convergence round unless there is unanimous support.
- Eliminate options with zero votes and an average score of 5 or lower.
- Eliminate options that are at least 2.5 average-score points behind the leader and are not listed as acceptable by any active debater.
- Eliminate options that a majority recommends eliminating and no debater chose.
- If the vote and score picture is essentially tied, eliminate nothing and ask the next round to break the tie.

### Step 6: Later Round Prompts

For each subsequent round, send the same debater/personality pairing a refined prompt containing the moderator memo and only the surviving options.

Use this prompt shape:

```markdown
## Many Brain One Decision: Round N of [MAX_ROUNDS]

### Decision Question
[question]

### Decision Brief
[background, constraints, criteria]

### Surviving Options
- A: [option]
- B: [option]

### Your Personality
You are `[personality-name]`.

[same personality paragraph as prior rounds]

### Previous Round Moderator Memo
[vote table, score table, strongest arguments, eliminated options, unresolved disagreement]

### Your Previous Position
[this debater's prior choice and reasoning summary]

### Instructions
Reconsider your position in light of the debate. You may stand firm or change your vote, but you must pick exactly one surviving option.

You must:

1. Address the strongest opposing argument.
2. Say whether your choice changed and why.
3. Score every surviving option from 1-10.
4. Name any options that should be eliminated.
5. End with the required machine-readable block.

BEGIN_MBOD_JSON
{
  "choice_id": "A",
  "previous_choice_id": "B",
  "confidence": 0.84,
  "reasoning_summary": "One sentence summary in your assigned voice.",
  "scores": {
    "A": 9,
    "B": 7
  },
  "can_accept": ["B"],
  "should_eliminate": [],
  "changed": true
}
END_MBOD_JSON
```

Run rounds until one of these happens:

- All active debaters choose the same option.
- The configured maximum round count has completed.

If only one option remains before consensus, run one final convergence round asking every active debater to choose it or explicitly argue for `NO_DECISION` if that option exists. If `NO_DECISION` does not exist, the single surviving option wins by elimination, but report that this was not unanimous consensus unless every debater chose it.

### Step 7: Finalize

The host thread makes the final call.

If consensus was reached, report the consensus option and the round. If no consensus after the configured maximum rounds, choose the winner by this order:

1. Highest final-round vote count.
2. Highest final-round average score.
3. Highest minimum score among debaters, as a least-regret tiebreaker.
4. Host judgment against the user's stated criteria.

Final response format:

```markdown
## Decision
**Outcome:** [option]
**Status:** Consensus in round N / Recommendation after [MAX_ROUNDS] rounds / Winner by elimination
**Confidence:** High / Medium / Low

## Final Tally
| Debater | Personality | Final Choice | Changed? | Confidence |
|---|---|---|---|---|

## Round Progression
| Round | Vote Split | Eliminated |
|---|---|---|

## Why This Won
[short synthesis of the decisive arguments]

## Dissent And Risks
[remaining objections, minority positions, or caveats]
```

If the user requested a follow-up artifact, such as an implementation plan, proposal, or recommendation memo, produce it after the decision summary.

### Dry Run

If the user specified `--dry-run`, do not launch agents. Show the planned question, options, evaluation criteria, debaters, personalities, number of rounds, and execution method.