Menu
Planner → Architect → Critic deliberation loop — produces a formally validated ADR
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Convert PDF/EPUB library to Markdown and generate Obsidian MOC notes
Hook-based compaction suggestions at logical task boundaries
Context window management — track spend, decide when to compact, preserve state
Session-start orientation — loads context, surfaces learnings, confirms registry
Quality and semantic review — catches what automated tools miss
Dual-dimension document quality gate — presentation rubric + hallucination grounding check
| name | consensus-plan |
| description | Planner → Architect → Critic deliberation loop — produces a formally validated ADR |
| version | 0.1.0 |
| level | 3 |
| triggers | ["consensus plan","deliberate on this","get a second opinion on the plan","validate this plan","/consensus-plan"] |
| pipeline | ["consensus-plan","plan-first"] |
| context_files | ["context/user.md","context/project.md","context/decisions.md"] |
| steps | [{"name":"Planner Draft","description":"Invoke the planner agent to produce an initial phased implementation plan"},{"name":"Architect Steelman","description":"Invoke the architect agent to find the strongest objection to the plan"},{"name":"Convergence Check","description":"Does the objection have a clear resolution? If yes, revise and proceed. If fundamental, loop back."},{"name":"Pre-Mortem (high-risk only)","description":"For HIGH risk plans — identify 3 specific failure scenarios before finalizing"},{"name":"ADR Output","description":"Write the formal Architecture Decision Record to context/decisions.md"},{"name":"Confirmation Gate","description":"Present the ADR. Wait for explicit approval before any implementation begins."}] |
A structured deliberation protocol that forces a plan through challenge before it is approved. The output is a formally validated ADR — not just a plan the author thinks is good, but a plan that survived its strongest objection.
Without deliberation, a plan reflects only the assumptions of the entity that created it. Those assumptions are invisible to the planner — they only become visible when someone with a different perspective examines the same problem. The Planner → Architect → Critic loop exists to surface blind spots before implementation, not during it.
Invoke the planner agent with the task description. The planner produces a structured plan (phases, steps, risks, parallel opportunities) in the standard format.
Do not modify the plan before passing it to the architect.
Invoke the architect agent with:
The architect must produce:
If the architect cannot find a meaningful objection, it must say so explicitly: "No material objection found. Plan is sound." This is a valid outcome — not a failure to engage.
After the architect steelman, invoke a third reviewer (researcher agent) with:
The peer reviewer must produce:
This step prevents anchoring: both the planner and architect may share a blind spot that only an unprimed reviewer can surface.
If the peer reviewer finds no unquestioned assumption, it must say so explicitly.
Nudge mechanism: After peer review, issue a forced challenge to the planner:
Nudge: The plan assumes [shared assumption identified by peer reviewer].
Challenge: [one question that would invalidate this assumption if the answer is no]
Planner must address this before the plan is finalized.
The planner responds inline. If the response is satisfactory, proceed to Convergence Check. If the response reveals a gap, return to Round 2 with the new information.
Assess the architect's objection:
Resolvable: The objection points to a specific step or assumption. The modification is clear. Revise the plan to incorporate it and proceed to ADR.
Fundamental: The objection challenges the approach itself, not a specific step. Return the plan to the planner with the objection stated explicitly. Run another round. Maximum 2 loops — if still unresolved after 2, escalate to the user.
No objection: Proceed directly to ADR.
For plans with risk level HIGH only:
"If this plan fails in 90 days, the 3 most likely causes are:"
Each scenario must include: what fails, why it fails (the mechanism), and what the early warning signal would be. Vague scenarios ("the team doesn't have time") do not count.
## [YYYY-MM-DD] [decision title]
Status: PROPOSED
Risk: LOW | MEDIUM | HIGH
### Context
[Why this decision is being made now — 2-3 sentences]
### Decision Drivers
1. [Driver]
2. [Driver]
3. [Driver]
### Options Considered
#### Option A: [chosen approach]
Pros: [list]
Cons: [list]
#### Option B: [alternative considered]
Pros: [list]
Cons: [list]
Rejected because: [specific reason]
### Decision
[What was decided]
### Rationale
[Why this option, referencing decision drivers]
### Consequences
Positive: [what gets better]
Negative: [what gets harder]
### Follow-ups
- [ ] [Action required as a result]
### Pre-Mortem (HIGH risk only)
Failure scenario 1: [mechanism + early warning]
Failure scenario 2: [mechanism + early warning]
Failure scenario 3: [mechanism + early warning]
### Architect Review
Objection raised: [what it was]
Resolution: [how the plan addressed it]
Reviewer verdict: APPROVED | NO OBJECTION
Write this to context/decisions.md.
ADRs are not permanent. Add a Revisit trigger field to every ADR:
### Revisit trigger
[Condition that would make this decision worth re-evaluating — e.g., "if X dependency is deprecated",
"if team size exceeds N", "if performance degrades past Y threshold"]
At session start (heartbeat) or at /retro, surface any ADR whose revisit trigger has been met.
Past decisions are reference — they are not binding if circumstances have changed.
Present the ADR to the user. Ask: "Confirmed? (yes / modify / no)"
Do not begin any implementation until the user confirms. A PROPOSED ADR is not an approved one.
| Situation | Use |
|---|---|
| 1-5 files, clear approach | plan-first |
| Complex feature, architectural tradeoffs | consensus-plan |
| Security-sensitive or irreversible operations | consensus-plan |
| Refactor of core module | consensus-plan |
| Uncertainty about the right approach | consensus-plan |
Do not skip the architect round because the plan "seems obvious." The architect finds objections to obvious plans most reliably.
Do not let the architect produce a list of objections. One strongest objection only — a list diffuses focus.
Do not loop more than twice. If the plan is still unresolved after 2 loops, the problem is not the plan — the problem is ambiguity in the task. Run deep-interview first.