Council
Use this skill for /octo:council and council-style requests.
EXECUTION CONTRACT: MANDATORY
/octo:council is a runner-backed workflow. Execute the real shell runner by default:
"${CLAUDE_PLUGIN_ROOT:-$HOME/.claude-octopus/plugin}/scripts/orchestrate.sh" council <user arguments>
Sandbox-safe invocation (required under Claude Code's sandbox). orchestrate.sh
must be the FIRST token of the command. The sandbox's unsandboxed-command allowlist is a
leading-anchored prefix match, so a command that begins with cd …, an inline
VAR=… env-assignment, or any other prefix will NOT match an …/orchestrate.sh *
entry — the runner then executes sandboxed and its codex/agy seat children fail to
write temp files (Operation not permitted, agy mkstemp in /var/folders), so the
council abandons the runner and falls back to direct single-provider dispatch. To run
against a worktree, pass --dir <path> (the runner already honors -d/--dir) instead
of wrapping in cd <path> && …; set any environment in a separate prior step or via a
leading env VAR=… /abs/path/orchestrate.sh council … so the resolvable binary path is
still first. Never prefix the runner with cd.
Do not simulate a council, role-play all members inside the current model, or answer directly in place of the runner. A single-model simulation must be explicitly requested with --simulate or --single-model; when used, label the output as single-model simulation and keep the generated summary.json path visible. Otherwise, missing provider quorum is a partial/failed council, not permission to silently downgrade.
Phase 0A: Interactive Clarification
If the user invokes /octo:council with an ambiguous task, missing goal/depth intent, uncertain implementation permission, or unclear research/corpus expectations, use AskUserQuestion before running the council runner. If the prompt already includes clear flags and a clear task, skip this phase and execute immediately.
Use 2-4 mutually exclusive choices per question, put the recommended option first, and map the answers to runner flags before execution. Do not end with a free-form question or a set of questions; present the choice interaction and wait for the answer.
Default council clarification:
AskUserQuestion({
questions: [
{
question: "How should the council handle this request?",
header: "Council Goal",
multiSelect: false,
options: [
{label: "Advice (Recommended)", description: "Return a structured recommendation without implementation"},
{label: "Decision", description: "Optimize for choosing between specific options"},
{label: "Implementation plan", description: "Produce a plan but do not edit files"},
{label: "Review", description: "Critique existing code, docs, or strategy"}
]
},
{
question: "How deep should the council go?",
header: "Depth",
multiSelect: false,
options: [
{label: "Standard (Recommended)", description: "Balanced cost and coverage"},
{label: "Quick", description: "Faster, lower-cost pass"},
{label: "Deep", description: "More critique and revision, higher cost"}
]
},
{
question: "Should the council use project research or corpus storage?",
header: "Context",
multiSelect: false,
options: [
{label: "No corpus (Recommended)", description: "Run with the provided prompt and write normal run artifacts"},
{label: "Research first", description: "Add --research-first before provider fanout"},
{label: "Append corpus", description: "Use --corpus-mode append for durable project notes"},
{label: "Require corpus", description: "Use --corpus-mode require and stop if no corpus workspace exists"}
]
}
]
})
Translate answers as follows:
- Advice, Decision, Implementation plan, or Review ->
--goal advice|decision|plan|review
- Quick, Standard, or Deep ->
--depth quick|standard|deep
- Research first ->
--research-first
- Append corpus or Require corpus ->
--corpus-mode append|require
Phase 0: Preflight
Collect or infer:
- goal:
advice, decision, plan, implement, or review
- domain:
auto, architecture, product, security, business, research, or docs
- style:
balanced, adversarial, implementation, executive, or red-team
- depth:
quick, standard, or deep
- members:
auto, 3, 5, or 7
- budget cap in USD
- providers and provider availability
- pinned personas
- implementation permission and worktree isolation
- whether research must happen before council fanout (
--research-first)
- whether findings, research, synthesis, and plans must be appended to the project corpus (
--corpus-mode append|require)
Show the selected council, provider availability, benchmark freshness, quorum requirement, and cost estimate before provider fanout. Re-check the budget before critique, revision, synthesis, and implementation planning so the run stops before the next phase would exceed --max-cost. If the run is a dry run, stop after this preflight and write summary.json.
If --research-first is set, gather local corpus evidence first, then current external sources when allowed. Store concise findings as run artifacts before provider fanout. If --corpus-mode append or --corpus-mode require is set, append the research notes, findings, synthesis, and implementation plan to the project's durable corpus conventions before claiming completion; require must stop when no corpus workspace is available.
Quorum
- quick requires at least one non-chair response plus a synthesis-capable chair
- standard and deep require at least two non-chair responses plus a synthesis-capable chair
- if the chair fails, retry once with the highest-scoring synthesis-capable fallback
- if quorum is lost, stop by default and present partial artifacts instead of pretending consensus exists
Council Procedure
- Independent advice: ask each selected persona for recommendation, assumptions, risks, implementation notes, and confidence.
- Cross-critique: for standard/deep runs, semi-anonymize responses and ask members to critique gaps, assumptions, and risks.
- Revision: for deep runs or high disagreement, let members revise their positions after critique.
- Chair synthesis: produce agreement, disagreement, minority reports, risk register, implementation path, confidence, and conditions that would change the recommendation.
- Ratify / veto: verifier, red-team, security, legal, finance, and medical roles can veto implementation for critical risks.
Implementation Gates
- Gate A: user accepts the council synthesis or asks for revision.
- Gate B: user accepts the concrete implementation plan generated from the synthesis.
- Gate C: execution proceeds through existing Octopus implementation safety behavior. This is a one-shot authorization for the accepted plan, not per-file approval, unless existing safety hooks detect destructive or risky actions.
Never implement from council output without explicit approval. Preserve disagreement, summarize risks, and keep vetoes visible in the final answer and artifacts.
Interactive Choice Handling
When the user needs to clarify scope, select a depth/provider/corpus option, approve a gate, or decide between follow-up actions, use AskUserQuestion with 2-4 mutually exclusive choices. Put the recommended choice first. Do not end with a free-form question or a set of questions; present the choice interaction and wait for the answer.
1---2name: skill-council3description: Run a configurable multi-LLM council with personas, budget caps, synthesis, veto gates, and optional implementation handoff.4---5
6# Council
7
8Use this skill for `/octo:council` and council-style requests.
9
10## EXECUTION CONTRACT: MANDATORY
11
12`/octo:council` is a runner-backed workflow. Execute the real shell runner by default:
13
14```bash
15"${CLAUDE_PLUGIN_ROOT:-$HOME/.claude-octopus/plugin}/scripts/orchestrate.sh" council <user arguments>
16```
17
18**Sandbox-safe invocation (required under Claude Code's sandbox).** `orchestrate.sh`
19must be the FIRST token of the command. The sandbox's unsandboxed-command allowlist is a
20leading-anchored prefix match, so a command that begins with `cd …`, an inline
21`VAR=… ` env-assignment, or any other prefix will NOT match an `…/orchestrate.sh *`
22entry — the runner then executes sandboxed and its `codex`/`agy` seat children fail to
23write temp files (`Operation not permitted`, agy `mkstemp` in `/var/folders`), so the
24council abandons the runner and falls back to direct single-provider dispatch. To run
25against a worktree, pass `--dir <path>` (the runner already honors `-d/--dir`) instead
26of wrapping in `cd <path> && …`; set any environment in a separate prior step or via a
27leading `env VAR=… /abs/path/orchestrate.sh council …` so the resolvable binary path is
28still first. Never prefix the runner with `cd`.
29
30Do not simulate a council, role-play all members inside the current model, or answer directly in place of the runner. A single-model simulation must be explicitly requested with `--simulate` or `--single-model`; when used, label the output as `single-model simulation` and keep the generated `summary.json` path visible. Otherwise, missing provider quorum is a partial/failed council, not permission to silently downgrade.
31
32## Phase 0A: Interactive Clarification
33
34If the user invokes `/octo:council` with an ambiguous task, missing goal/depth intent, uncertain implementation permission, or unclear research/corpus expectations, use `AskUserQuestion` before running the council runner. If the prompt already includes clear flags and a clear task, skip this phase and execute immediately.
35
36Use 2-4 mutually exclusive choices per question, put the recommended option first, and map the answers to runner flags before execution. Do not end with a free-form question or a set of questions; present the choice interaction and wait for the answer.
37
38Default council clarification:
39
40```javascript
41AskUserQuestion({
42 questions: [
43 {
44 question: "How should the council handle this request?",
45 header: "Council Goal",
46 multiSelect: false,
47 options: [
48 {label: "Advice (Recommended)", description: "Return a structured recommendation without implementation"},
49 {label: "Decision", description: "Optimize for choosing between specific options"},
50 {label: "Implementation plan", description: "Produce a plan but do not edit files"},
51 {label: "Review", description: "Critique existing code, docs, or strategy"}
52 ]
53 },
54 {
55 question: "How deep should the council go?",
56 header: "Depth",
57 multiSelect: false,
58 options: [
59 {label: "Standard (Recommended)", description: "Balanced cost and coverage"},
60 {label: "Quick", description: "Faster, lower-cost pass"},
61 {label: "Deep", description: "More critique and revision, higher cost"}
62 ]
63 },
64 {
65 question: "Should the council use project research or corpus storage?",
66 header: "Context",
67 multiSelect: false,
68 options: [
69 {label: "No corpus (Recommended)", description: "Run with the provided prompt and write normal run artifacts"},
70 {label: "Research first", description: "Add --research-first before provider fanout"},
71 {label: "Append corpus", description: "Use --corpus-mode append for durable project notes"},
72 {label: "Require corpus", description: "Use --corpus-mode require and stop if no corpus workspace exists"}
73 ]
74 }
75 ]
76})
77```
78
79Translate answers as follows:
80
81- Advice, Decision, Implementation plan, or Review -> `--goal advice|decision|plan|review`
82- Quick, Standard, or Deep -> `--depth quick|standard|deep`
83- Research first -> `--research-first`
84- Append corpus or Require corpus -> `--corpus-mode append|require`
85
86## Phase 0: Preflight
87
88Collect or infer:
89
90- goal: `advice`, `decision`, `plan`, `implement`, or `review`
91- domain: `auto`, `architecture`, `product`, `security`, `business`, `research`, or `docs`
92- style: `balanced`, `adversarial`, `implementation`, `executive`, or `red-team`
93- depth: `quick`, `standard`, or `deep`
94- members: `auto`, `3`, `5`, or `7`
95- budget cap in USD
96- providers and provider availability
97- pinned personas
98- implementation permission and worktree isolation
99- whether research must happen before council fanout (`--research-first`)
100- whether findings, research, synthesis, and plans must be appended to the project corpus (`--corpus-mode append|require`)
101
102Show the selected council, provider availability, benchmark freshness, quorum requirement, and cost estimate before provider fanout. Re-check the budget before critique, revision, synthesis, and implementation planning so the run stops before the next phase would exceed `--max-cost`. If the run is a dry run, stop after this preflight and write `summary.json`.
103
104If `--research-first` is set, gather local corpus evidence first, then current external sources when allowed. Store concise findings as run artifacts before provider fanout. If `--corpus-mode append` or `--corpus-mode require` is set, append the research notes, findings, synthesis, and implementation plan to the project's durable corpus conventions before claiming completion; `require` must stop when no corpus workspace is available.
105
106## Quorum
107
108- quick requires at least one non-chair response plus a synthesis-capable chair
109- standard and deep require at least two non-chair responses plus a synthesis-capable chair
110- if the chair fails, retry once with the highest-scoring synthesis-capable fallback
111- if quorum is lost, stop by default and present partial artifacts instead of pretending consensus exists
112
113## Council Procedure
114
1151. **Independent advice:** ask each selected persona for recommendation, assumptions, risks, implementation notes, and confidence.
1162. **Cross-critique:** for standard/deep runs, semi-anonymize responses and ask members to critique gaps, assumptions, and risks.
1173. **Revision:** for deep runs or high disagreement, let members revise their positions after critique.
1184. **Chair synthesis:** produce agreement, disagreement, minority reports, risk register, implementation path, confidence, and conditions that would change the recommendation.
1195. **Ratify / veto:** verifier, red-team, security, legal, finance, and medical roles can veto implementation for critical risks.
120
121## Implementation Gates
122
123- **Gate A:** user accepts the council synthesis or asks for revision.
124- **Gate B:** user accepts the concrete implementation plan generated from the synthesis.
125- **Gate C:** execution proceeds through existing Octopus implementation safety behavior. This is a one-shot authorization for the accepted plan, not per-file approval, unless existing safety hooks detect destructive or risky actions.
126
127Never implement from council output without explicit approval. Preserve disagreement, summarize risks, and keep vetoes visible in the final answer and artifacts.
128
129## Interactive Choice Handling
130
131When the user needs to clarify scope, select a depth/provider/corpus option, approve a gate, or decide between follow-up actions, use `AskUserQuestion` with 2-4 mutually exclusive choices. Put the recommended choice first. Do not end with a free-form question or a set of questions; present the choice interaction and wait for the answer.
nyldn