| name | start-decide-council |
| description | Launch an LLM-Council-Decide panel for a decision the user wants analysed through formal decision-making frameworks. Use when the user says things like "analyse this decision", "should I X or Y", "help me decide", "run a council on this", "/start-decide-council", or provides a decision brief in the LLM-Council-Decide repo. Captures the brief (free-text or voice transcript), optionally auto-selects the framework panel, invokes the council, and surfaces the dossier + PDF. |
Start a Decide Council
You are operating inside the LLM-Council-Decide repo. This skill walks the user through running a council session.
Preconditions
- Confirm the repo root contains
backend/main.py and prompts/framework_selector.md. If not, the user has invoked this skill outside the repo — tell them.
- Check
.env has OPENROUTER_API_KEY. If missing, tell the user exactly what to put there (copy from .env.example). Do not invent or ask for a key value yourself.
- Ensure dependencies are installed:
uv sync. Run it if the venv is missing.
Step 1 — Capture the decision brief
Ask the user for the brief if one has not already been provided. Accept any of:
- A path to an existing markdown/text file.
- Free-form text pasted into the conversation.
- A voice-transcription paste (the repo assumes voice is welcome).
If the user gives you free-form text, save it to briefs/<short-slug>-YYYY-MM-DD.md (create briefs/ if absent; it is gitignored by default but safe to commit if the user wants to keep it).
Do not edit or "clean up" the user's phrasing. The context parser is designed to read raw human input, including uncertainty, hedging, and emotional loading.
Step 2 — Choose the panel
Ask the user: "Pick your framework panel yourself, or should I auto-select?"
- If they say auto-select, proceed to Step 3 with
--auto-select.
- If they want to pick, run
uv run python -m backend.main --list and show them the catalogue. Accept up to 5 comma-separated keys.
- If they are unsure or don't answer, default to
--auto-select — it's the right answer for most briefs.
Step 3 — Run the council
Run:
uv run python -m backend.main --brief <path-to-brief> [--auto-select | --frameworks key1,key2,...]
While it runs, tell the user what panel was chosen (the CLI prints this) and approximately how long to expect (tens of seconds to a couple of minutes depending on model throughput).
Step 4 — Surface the output
When the run completes:
- Show the dossier content to the user (printed by the CLI).
- Report the PDF path.
- If the user wants to iterate — e.g., re-run with a different panel, add missing context, or explore a specific framework's reasoning — offer to edit the brief and re-run.
Step 5 — Save & commit (only if asked)
If the user asks to keep the session:
- Move the brief + generated
out/<timestamp>/ directory to archive/<slug>/ so it survives a gitignore purge.
- Commit only with explicit permission.
Failure modes to handle gracefully
- Missing API key: stop immediately, explain, do not attempt workarounds.
- Selector returns no frameworks: fall back to the default panel and tell the user.
- Typst not installed: the CLI's
--no-pdf flag still gives the dossier; tell the user how to install Typst and that the PDF can be generated separately via the typst-council-report skill once installed.
- Model timeout / rate-limit: report the specific failure; offer to retry with a smaller panel.
Out of scope
Do not modify framework prompts or the Chairman prompt through this skill. If the user wants to edit how a framework reasons, that is a direct edit to prompts/framework_*.md, not part of a council run.
