MECE decompose

A quorum spends its budget on parallel miners; this skill decides what each miner owns. Mutually exclusive branches mean no duplicated miner spend. Collectively exhaustive branches mean no blind spot the judge panel has to catch expensively after the fact. The judges already do overlap-and-gap detection post-hoc — this is the same operation run pre-hoc, before the money is spent.

It also stands alone: spec reviews, plan audits, "did we cover everything" questions.

Two modes

Decompose (given a question) — build the tree:

1. Bound the domain first. One sentence each for in-scope and out-of-scope. Most "incomplete" breakdowns are actually unbounded ones.
2. One dimension per tier. Split by exactly one axis at each level (by component, by lifecycle stage, by stakeholder, by failure mode — never a mix). Mixing axes in one tier is where overlaps come from.
3. Two to three levels deep, no more. Leaves below that are tasks, not questions.
4. Code each leaf: [F]act (established), [I]nference (derived, show from what), [A]ssumption (unverified — say what evidence would settle it), plus a confidence word (high/medium/low).
5. Mark the kill-test branch: the one branch which, if it fails, invalidates the top-level answer. It gets mined first and hardest.
6. Self-validate before presenting (the checklist below).

Validate (given an existing breakdown — a spec, plan, miner roster, or org of work): map its implicit structure, run the checklist, report findings severity-ranked, and ask before fixing — restructuring someone's decomposition uninvited destroys the thinking encoded in it.

The validation checklist

• Overlap test — pairwise across every branch: can one concrete item land in two branches? Name the item. ("Same thing, different name" is the commonest failure.)
• Gap test — reverse-check: name three things adjacent to the domain and show each is either in a branch or explicitly out-of-scope. An implicit "everything else" bucket fails this; make it explicit or close it.
• Axis consistency — is any tier mixing dimensions (a "by layer" branch next to a "by concern" branch)? That tier gets re-split.
• Testability — for each leaf: can a single miner actually resolve this with evidence, or is it unfalsifiable as phrased? An untestable leaf is a essay prompt, not a work assignment — rephrase until a verifier could rule on it.
• Abstraction level — leaves at one tier should be the same size of question; one giant leaf beside three trivial ones means the giant one needs its own split.

Trees are revisable, not one-shot

A wrong branch discovered mid-run does not cascade: when a miner's findings invalidate a branch's assumption, re-decompose that branch and re-dispatch it — never patch the conclusions to fit a stale tree, and never let the whole tree re-derive from scratch mid-flight. Static upfront decomposition that nobody revisits is how a wrong early guess multiplies through everything downstream.

Wiring into a quorum

The pre-step, run before any miners spawn:

decompose the question → validate the tree → one branch = one miner's charter
→ kill-test branch mined first → miner findings that break a branch trigger
  re-decomposition of that branch only

The miner's charter quotes its leaf verbatim, including the evidence code — a miner assigned an [A]ssumption leaf knows its job is to settle the assumption, not to build on it.

Degraded mode

Nothing to install; this is a thinking discipline. With no subagents at all, the tree still earns its keep: work the branches sequentially, kill-test first, and the overlap/gap checklist still catches the holes a linear plan hides.

Related skills

• quorum — the orchestrator this feeds; the tree becomes the miner roster
• quorum-lenses — lenses color how a miner looks; branches decide where
• quorum-verification — verifies findings; this skill verifies coverage
• quorum-judging — judges catch overlap/gap post-hoc; this is the pre-hoc twin