Reaching a consensus plan before you build

Related: this skill produces a plan. To have one judged by a declared panel before you commit to it, run_team(name, target="plan", text=...) - see marshal-adversarial-review. Use that when the question is "is this plan sound?"; use the loop below when the question is still "what should the plan even be?"

When what to do is clear you just decompose and delegate (marshal-orchestrate). When how to do it is contested - several plausible designs, fuzzy scope, an expensive-to-undo direction - you first turn the question into an evidenced plan that survived independent scrutiny. The loop is frame -> solve (in isolation) -> judge -> converge or build.

This is not one agent's plan. It is biased, independent, multi-angle convergence: each solver starts from a different prior, proposes without seeing the others, and an independent judge arbitrates - it never authors a fourth plan of its own.

When to use

• A non-trivial goal where the approach is genuinely contested, or a wrong turn is costly (a schema, a public API, a migration strategy, a refactor boundary).
• Not for obvious tasks - reaching for consensus on a clear change is wasted spend; just orchestrate.

The three rules that make it work

• Biased. Each solver holds ONE prior (below) and argues it. Don't ask one agent for "the best plan" - that collapses to a single opinion.
• Independent. Solvers must not see each other's plans. Spawn them together so they run in parallel isolation; only the judge reads all of them.
• Sealed. Each solver ends with one parseable line: PLAN: propose|abstain - <one-line approach>, above a short plan body (scope, files, key decisions, what it explicitly will NOT do).

1. Frame the question

Write ONE concrete, narrow question, plus the constraints/rules that govern it and the minimal files or context a solver needs to answer. Vague questions produce vague plans.

2. Spawn the solvers (no-peek, read-only)

Route to read-only clients (they inspect the repo and produce a plan, not edits) and give each the same question + its prior + the required PLAN: line. Run them together so they cannot see each other:

run_many([
  {client: <read-only>, goal: MINIMAL_PRIOR    + question, task_id: "plan.<id>"},
  {client: <read-only>, goal: STRUCTURAL_PRIOR  + question, task_id: "plan.<id>"},
  {client: <read-only>, goal: DELETE_PRIOR      + question, task_id: "plan.<id>"},
])

Share one task_id so usage() / report() group the round. The priors:

• minimal - the smallest viable change that resolves the goal; explicitly do NOT over-engineer.
• structural - the structurally clean design; accept higher cost (a helper, an abstraction, an extra handoff) to land something an architecture review won't reject later.
• delete - question the necessity. Can this be solved by deleting or collapsing, or not built at all? If it must be built, abstain and let minimal/structural win.

3. Judge - converge, don't author

Feed the three sealed plans to one independent judge agent. It arbitrates between the proposals; it must not invent a fourth design not present in any solver (that means it's solving, not judging). It emits exactly one:

• consensus - the proposals agree (same boundary, same files, no contradictory choices). Output the one concrete converged plan.
• converge - they disagree but are close: narrow the question to the open disagreement and re-run step 2.
• escalate - genuinely stuck or the goal is ill-posed. Stop and bring it to a human.

Even when a direction looks obvious, run the gate: it turns a hunch into a plan with stated scope, files, and non-goals.

4. Converge loop

On converge, re-run the solvers with the narrowed question. Cap at ~3 rounds. If a round makes no progress (same split twice), escalate to a human or drop the goal - never loop forever.

5. Build

On consensus, the converged plan is your spec: hand it to marshal-orchestrate (decompose into independent tasks -> spawn -> review -> integrate), and gate the result with marshal-review-gate when the change warrants a quorum.

Invariants to respect

• Solvers and judge are headless - the question + prior in the prompt is all they get; no questions.
• Independent means parallel + isolated; only the judge sees all plans, never a solver.
• The judge converges among the proposals; it never authors a new plan of its own.
• An obvious direction still passes the gate; cap the rounds and escalate - never loop forever.