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 deleg...
Installs into .claude/skills of the current project.
Sponsors
SSkills DirectorySkills Directory
Is that skill safe to install?
SSkills DirectorySkills Directory
Know which skills are safe — weekly.
Are you the author of Consensus Delegation?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/fritzprix-consensus-delegation)
---
name: consensus-delegation
description: 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).
---
# 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 template IDs in `agent__spawnSession` (never pass a `sessionId`)
- `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__spawnSession(configId="...", 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__spawnSession(..., 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