Marshal plan consensus

Skill chiruu12/marshal/skills/marshal-plan-consensus

Reach a consensus on the APPROACH before committing a fleet to build it. Spawn several biased, independent solvers that each propose a plan for the same question, then an independent judge that converges them into one concrete plan (or narrows the question and re-runs). Use when the approach is contested - multiple valid designs, ambiguous scope, or a costly wrong turn - not for obvious work. The engine runs the agents; this playbook is the judgment. Hand the converged plan to marshal-orchestrate to build it.From its SKILL.md

Install

npx -y skills add chiruu12/marshal --skill marshal-plan-consensus

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.1 KB, as published. Nobody here has run it

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.