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...
Scanned 9/28/2026
Install to Claude Code
npx -y skills add fritzprix/libr-agent --skill consensus-delegation --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Consensus Delegation?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/fritzprix-consensus-delegation)More formats (shields.io, HTML) on the badges page.
---
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
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!