# Consensus Delegation

> Use when the user needs to evaluate the same question from different perspectives by orchestrating multiple specialized child sessions, collecting their independent conclusions, and reconciling disagreements through parent-mediated follow-ups. Suitable for code review triangulation, architecture or risk assessment, security vs performance tradeoff analysis, or any bounded decision that benefits from 2-4 distinct expert viewpoints—not for persistent teams (teamwork/org) or single one-off delegation (delegate).

- Skill: `fritzprix/consensus-delegation` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add fritzprix/consensus-delegation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fritzprix/consensus-delegation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: fritzprix (https://skillmd.com/u/fritzprix)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fritzprix/consensus-delegation

---


# Consensus via Delegation

Use this skill when one parent session should **compare independent expert opinions** on the same scoped question, then synthesize a final answer.

This is parent-mediated orchestration: child sessions do not talk to each other. The parent spawns specialists, collects results, detects disagreement, and sends targeted follow-ups.

For general spawn/monitor mechanics and workspace isolation rules, follow `delegate` first. Read this skill when you need the **multi-reviewer workflow**, not a single child task.

## Core Rules

1. **Same question, same scope.** Every child must receive the same objective, boundaries, and output shape. Change only the perspective or assistant specialization.
2. **Shared evidence when code matters.** If reviewers must inspect the same repo, use `workspaceOverride` with the parent's effective workspace path—or paste critical excerpts into every handoff. Children do not inherit parent workspace or `agents.md` automatically.
3. **Parent is the hub.** Only the parent can `agent__checkSession` or `agent__messageToSession` its descendants. Sibling sessions cannot see or message each other.
4. **Structured handoffs, human synthesis.** Ask each child for a fixed section layout (verdict, findings, risks, confidence). The parent compares text results; there is no built-in vote or merge algorithm.
5. **Do not blindly trust children.** Verify file paths, claims, and scope before presenting a final answer.

## Workflow

### 1. Frame the decision

Define before spawning anything:

- the exact question or artifact under review
- in-scope paths/modules and hard boundaries
- the output sections every child must return
- what counts as agreement vs material disagreement

### 2. Pick specialists (reuse first)

Default: **reuse existing assistant configurations and suitable child sessions** and put the review lens in the handoff task. Do **not** `agent__createAgent` just to bake a perspective into the system prompt when a capable generalist already exists.

- `agent__listAgents(type="configs")` to discover assistants; use returned IDs in `agent__startSession`
- `agent__listAgents(type="sessions")` to find an Idle child with the same assistant ID and compatible workspace; use `agent__messageToSession(reset=true)` for a fresh review assignment when reuse is safe
- Match on **capability**, not perfect persona: any assistant that can read the repo / reason about the artifact is eligible. Coding, research, and general review configs are fine for security / correctness / coverage lenses when the task text states the lens
- Differ perspectives via the shared handoff wrapper (`You are reviewing as: [PERSPECTIVE]`) and lens-specific bullets — see `references/workflow-templates.md`
- Prefer distinct existing configs when available (e.g. coding + research) so sessions are not identical clones of the parent; still inject the lens in the task
- `agent__createAgent` is allowed when **no existing config can do the work** (empty list, or none with the needed tools/skills). Create one reusable generalist (or the minimum set), then inject lenses in the handoff — do not create one config per panel seat
- If the user asks to keep a durable named specialist for future runs, create that with their confirmation
- Keep the panel small (usually 2-4). More reviewers add noise and hit fanout/concurrency limits

### 3. Prepare identical handoffs

Each task should differ only in **review lens**, not in scope or deliverable format.

Include:

- shared objective and scope
- shared output template (see `references/workflow-templates.md`)
- critical workspace rules copied from the parent when needed
- absolute paths or identifiers the child must use

When all reviewers need the same codebase, start each child with the same `workspaceOverride`.

### 4. Spawn and run

Default pattern:

1. Inspect existing sessions and reuse a suitable Idle matching-role child with `agent__messageToSession`; use `agent__startSession(agentId="...", task="...", waitForResult=false, workspaceOverride="...")` only when no suitable child exists, a different role/workspace is needed, or parallel capacity requires another session
2. Use the session inventory for child IDs and status—`agent__listAgents` does not return review results
3. Collect with `agent__checkSession(sessionId)` or `agent__checkSession(sessionId, wait=true)` for actual conclusions

Notes:

- Prefer `waitForResult=false` on spawn so multiple children can run while the parent plans the synthesis
- Tool calls in one turn execute sequentially; children still run in parallel once started, subject to the global active-session slot limit (default 4, configurable via `maxConcurrentActiveSessions`)
- While `agent__checkSession(wait=true)` blocks, the parent releases its active slot so children can finish—use waits deliberately

### 5. Compare results

For each child result, extract:

- verdict or recommendation
- top findings with evidence (paths, symbols, commands)
- risks and confidence level

Flag **material disagreement** when verdicts conflict or findings contradict on the same fact. Minor wording differences are not disagreement.

### 6. Reconcile (only when needed)

When perspectives conflict:

1. State the specific conflict (fact, tradeoff, or recommendation)
2. `agent__compactSessionContext(sessionId)` on children with long histories before large follow-ups
3. `agent__messageToSession` each relevant child with the opposing finding and ask for a focused re-check
4. `agent__checkSession(..., wait=true)` again after follow-ups
5. Stop after 1-2 reconciliation rounds unless new blocking facts appear

Read `references/reconciliation.md` for round templates and stop conditions.

### 7. Synthesize in the parent

Produce the final answer yourself:

- summarize agreed facts
- explain unresolved tradeoffs
- state your recommendation and what each perspective contributed
- cite which child sessions supported each conclusion

Do not present a single child's output as the final answer without comparison.

## Builtin Tools

| Step | Tool |
| --- | --- |
| Discover assistants | `agent__listAgents(type="configs")` |
| Create specialist | `agent__createAgent(...)` — when no usable existing config; not one config per lens |
| Assign reviewer | `agent__messageToSession(..., reset=true)` when a matching Idle child exists; otherwise `agent__startSession(..., waitForResult=false)` |
| Inspect children | `agent__listAgents(type="sessions")` — IDs and status only |
| Poll or wait | `agent__checkSession(sessionId)` / `agent__checkSession(sessionId, wait=true)` — results |
| Reconcile | `agent__messageToSession(sessionId, message)` |
| Stop stuck work | `agent__stopSession(sessionId)` |
| Long histories | `agent__compactSessionContext(sessionId)` |

## Common Mistakes

- **Creating one config per lens** — pollutes the assistant list; reuse configs and inject the lens in the task
- **Treating "no exact persona" as "must create"** — if a generalist exists, a clear PERSPECTIVE handoff is enough; create only when nothing usable exists
- **Different scopes per child** — comparisons become meaningless; keep scope identical
- **Assuming shared workspace without `workspaceOverride`** — reviewers inspect different files
- **Expecting children to respond to each other** — repackage opposing views in the parent message
- **Skipping output format** — parent cannot compare unstructured prose reliably
- **Trusting verdicts without evidence** — re-open files or traces before deciding
- **Blocking the parent on every spawn** — use async spawn + targeted waits
- **Ignoring paused/error sessions** — recover with `agent__messageToSession`, not another blind `agent__checkSession`

## References

- `references/workflow-templates.md` — handoff and output templates by scenario
- `references/reconciliation.md` — disagreement handling, follow-up rounds, stop rules