---
name: decision-panel
description: Run a bounded multi-model architecture decision panel through Knodr MCP.
---

# Decision Panel

Use this skill when the user wants a consolidated architecture or design decision from
several independent model vendors. The argument is the decision question.

The executable graph is `flows/decision-panel.knodrflow`. The skill prepares the run;
the flow owns discovery, debate, arbitration, the three-iteration cap, and final synthesis.

## Preconditions

- Require the Knodr MCP tools, including `validate_flow`, `start_run`, and
  `get_run_status`.
- Require `flows/decision-panel.knodrflow` under the Knodr MCP project root.
- Require authenticated `claude` and `codex` CLIs.
- Require Knodr credentials named `gemini`, `grok`, `deepseek`, and `minimax`.
- Tell the user that a run commonly takes 40–90 minutes. The worst case invokes 27
  agents and reserves up to 12,000 seconds.

## Prepare the run

1. Turn the argument into one decidable question. Preserve the user's language.
2. Collect every document, repository, and file set named by the user or clearly
   established in the conversation. Resolve every path to an absolute path.
3. If relevant basis material exists only in chat, write it to
   `<workdir>\.panel-tmp\docs\notes-<timestamp>.md`.
4. Set `workdir` to the deepest common ancestor of all material paths. Never use a
   drive root. If the only common ancestor is a drive root, choose the primary
   repository and copy outside documents into `<workdir>\.panel-tmp\docs\`.
5. Under `<workdir>\.panel-tmp\`, allocate:
   - `dossier-<timestamp>.md`
   - `discovery-<timestamp>.md`
   - `final-<timestamp>.md`
6. Build `materials` as a Markdown bullet list. Each line contains the material type,
   absolute path, and a short focus hint.

## Validate and start

Call `validate_flow`:

```json
{
  "path": "flows/decision-panel.knodrflow"
}
```

Stop and report every diagnostic if `ok` is false.

Call `start_run`:

```json
{
  "path": "flows/decision-panel.knodrflow",
  "inputs": {
    "question": "<decision question>",
    "materials": "<Markdown bullet list>",
    "workdir": "<absolute common ancestor>",
    "dossierPath": "<absolute dossier path>",
    "rawPath": "<absolute discovery path>",
    "finalPath": "<absolute final path>"
  },
  "timeoutSeconds": 12000
}
```

Capture the returned `runId`.

## Observe

- Poll `get_run_status` until the state is `success`, `failed`, or `cancelled`.
- Space polls by at least 60 seconds. Use the client's monitoring or wake-up mechanism
  instead of blocking foreground sleep.
- For a progress glimpse, read the tail of the append-only dossier.
- Never call `get_run_snapshot` for this flow. Agent stdout and stderr can make the
  snapshot too large for the client context.

## Present the result

On success:

1. Read `finalPath`.
2. Search `dossierPath` for `### Arbiter verdict` and identify the verdict history.
3. Report whether the panel passed at iteration 1, 2, or 3, or reached the cap without
   convergence.
4. Summarize the decision in 3–5 sentences.
5. Surface unresolved dissent and risks.
6. Return `finalPath`, `dossierPath`, and `runId`. Keep the dossier as the audit trail.

On failure or cancellation:

1. Read and summarize the partial dossier.
2. Report the state, error, and failed node from `get_run_status`.
3. Call `get_run_logs` for the relevant tail.
4. Return the partial artifact paths and `runId`.