@skhema/cli 0.4.4 → 0.4.5

package/skills/skhema-communicate/references/board-update.md

@@ -0,0 +1,93 @@
+# Board update
+
+The audience oversees the strategy; they do not execute it. They carry
+accountability for it and hold resources you need. What they must DO with
+your update: satisfy themselves the strategy is still sound, decide on the
+asks you bring, and knowingly accept the risks that are being carried. Give
+them exactly what those three acts require, and nothing that only flatters.
+
+A board update is not a status report. Activity is not the unit; decisions,
+evidence, risk, and asks are. If a line doesn't help them govern, cut it.
+
+## The moves
+
+1. **Get the baseline.** Ask: what did the board last see, and when? A board
+   update is a delta. If there is no prior, state the strategy's through-line
+   in one paragraph so the rest has an anchor.
+2. **Ask what actually changed.** Since the last update: what did you decide,
+   what did you learn, what got riskier or safer? Everything below comes from
+   this, not from a calendar of what happened.
+3. **Draft the five sections** below, in this order.
+4. **Force every ask to have an owner and a default.** An ask with no
+   decision attached is theatre. See section 5.
+5. **Strip the theatre.** Read it back and delete anything that is there to
+   impress rather than to inform a governance decision.
+
+## The shape
+
+Five sections. One page if you can.
+
+1. **The through-line.** One short paragraph: what this strategy is and
+   whether it has changed. If it hasn't changed, say so in a sentence — that
+   itself is information the board needs.
+2. **Decisions made.** What you decided since last time, each with the
+   judgment behind it in one line — not just the outcome, the reason. The
+   board is accountable for the direction; they need the "why", not just the
+   "what".
+3. **Evidence moved.** What you learned that changed your confidence. A bet
+   that paid off or didn't, a number that came in, an assumption now
+   confirmed or killed. State which way it moved your confidence and what you
+   did about it.
+4. **Risks carried.** The live risks, each with an owner and a trigger —
+   "if X happens, we do Y". A risk with no owner and no trigger is a worry,
+   not a managed risk, and the board can't accept it.
+5. **Asks.** The specific decisions or resources you need FROM the board.
+   Each ask states: what you're asking for, the decision it unblocks, and
+   **the default if they don't act**. The default is what turns a discussion
+   into a decision.
+
+## What good looks like
+
+- A board member could vote on every ask without asking a clarifying
+  question first.
+- Every decision reported comes with its reason, so the board can challenge
+  the reasoning, not just the outcome.
+- Every risk has a name next to it and a stated trigger.
+- The asks are up top or clearly flagged, never buried in paragraph six.
+- It is shorter than they expected and they still know more.
+
+## Failure modes to catch
+
+- **Activity dump.** "Here's everything we did." The board governs
+  decisions and risk, not effort. Replace the timeline with the four
+  substantive sections.
+- **Buried ask.** The thing you actually need is in the last sentence. Move
+  it up; a board update exists to get the asks decided.
+- **Ownerless risk.** Risks listed with no owner and no trigger. The board
+  cannot knowingly accept a risk nobody owns. Add both or drop the line.
+- **Vanity metrics.** Numbers that go up and flatter but wouldn't change any
+  governance decision. If a metric wouldn't alter an ask or a risk, it
+  doesn't belong in a board update.
+- **No confidence direction.** Evidence reported without saying which way it
+  moved you. "We ran the pilot" is activity; "the pilot missed, so we've cut
+  our confidence in the channel and paused spend" is evidence moved.
+- **Reassurance in place of asks.** A whole update that reports comfort and
+  asks for nothing. If there is genuinely nothing to decide, that is a
+  one-line update, not a deck.
+
+## Save it as a workspace document
+
+In the Skhema environment, the artifact you just wrote has a home: save it
+as a workspace document so it stays versioned with the strategy and cites
+the elements it stands on.
+
+```sh
+echo '{"title":"<title>","docType":"board_update","content":"<the markdown you wrote>","elementRefs":["<element-id>", "…"]}' > doc.json
+skhema document create --workspace <workspace-id> --file doc.json
+```
+
+Put every element you drew on into `elementRefs` — that tether is what lets
+a later calibration pass tell the reader which briefs were built on a
+judgment that has since gone stale. Working outside the Skhema environment?
+The artifact is still complete as a file; save it wherever your team keeps
+decisions.

package/skills/skhema-communicate/references/decision-brief.md

@@ -0,0 +1,93 @@
+# Decision brief
+
+One decision. One page. The audience reads it to say yes or no, and to have
+a record of why later. What they must DO with it: judge the reasoning — not
+just receive the recommendation — and be able to reconstruct, months from
+now, what was known and what was merely believed when the call was made.
+
+The discipline that makes a decision brief work: **evidence before
+recommendation, and reversibility called out first.** A reader handed the
+recommendation first can only agree or disagree with you; a reader handed
+the evidence first can form their own view and then check yours against it.
+
+## The moves
+
+1. **State the decision as a command, in one sentence.** "We will build X in
+   house." Not "should we build or buy?" — a brief resolves a fork, it
+   doesn't host the debate.
+2. **Classify reversibility first.** One-way door or two-way door? Can we
+   undo this cheaply, or are we stuck with it? This sets how much rigour the
+   rest of the brief deserves — over-analysing a reversible call wastes
+   everyone; under-analysing an irreversible one is how disasters get
+   waved through.
+3. **Lay out the evidence before your recommendation.** Separate what is
+   known from what is assumed, and mark the confidence on each. The reader
+   should be able to reach the recommendation themselves from the evidence
+   you show.
+4. **Show the options you rejected, each as a claim, with why.** A decision
+   with only one option shown isn't a decision, it's an announcement.
+5. **Record the dissent.** Who disagreed, and their actual reason, in their
+   terms — not smoothed into consensus. Disagreement erased from the record
+   is disagreement you'll relitigate later with no memory of why.
+6. **State the revisit trigger.** What would make us reopen this — a number,
+   an event, a date.
+
+## The shape (one page)
+
+1. **The decision.** One sentence, imperative. What we will do.
+2. **Owner and date.** Who is accountable, and when it was decided.
+3. **Reversible or not.** Two-way door (undo cheaply) or one-way (committed).
+   Say which, and let it set the depth of everything below.
+4. **The evidence.** Facts first, each marked known or assumed, with
+   confidence. This comes before the recommendation, deliberately.
+5. **Options considered.** Each stated as a claim, each with why it was
+   rejected — including the option of doing nothing.
+6. **Recommendation.** The call, and the judgment that gets you from the
+   evidence to it.
+7. **Dissent.** Who disagreed and why, recorded straight.
+8. **Revisit trigger.** What would make us reopen this.
+
+## What good looks like
+
+- A reader could reach your recommendation from your evidence section
+  before they read your recommendation.
+- The reversibility call is explicit and the depth of analysis matches it.
+- Facts and assumptions are visibly separated; no assumption is dressed as
+  a fact.
+- The strongest objection is on the page in its own words.
+- A year later, someone can see exactly what was known and believed at
+  decision time.
+
+## Failure modes to catch
+
+- **Recommendation first.** The call leads and the evidence is arranged to
+  support it. The reader can only rubber-stamp. Put evidence first.
+- **No reversibility call.** The brief agonises over a two-way door, or
+  nods through a one-way one. Classify it and match the rigour.
+- **Assumptions as facts.** Beliefs stated in the confident voice of
+  evidence. Mark each one; a claim with no evidence behind it is an
+  assumption and gets labelled as one.
+- **Straw options.** Alternatives listed only to be knocked down. Show the
+  real case for each before the reason it lost.
+- **Sanded-off dissent.** "The team is aligned" when someone wasn't. Record
+  the objection; consensus theatre destroys the paper trail's whole value.
+- **No revisit trigger.** The decision is framed as permanent when it isn't.
+  State what would reopen it, so a changed world reopens it on purpose
+  rather than by crisis.
+
+## Save it as a workspace document
+
+In the Skhema environment, the artifact you just wrote has a home: save it
+as a workspace document so it stays versioned with the strategy and cites
+the elements it stands on.
+
+```sh
+echo '{"title":"<title>","docType":"decision_brief","content":"<the markdown you wrote>","elementRefs":["<element-id>", "…"]}' > doc.json
+skhema document create --workspace <workspace-id> --file doc.json
+```
+
+Put every element you drew on into `elementRefs` — that tether is what lets
+a later calibration pass tell the reader which briefs were built on a
+judgment that has since gone stale. Working outside the Skhema environment?
+The artifact is still complete as a file; save it wherever your team keeps
+decisions.

package/skills/skhema-communicate/references/team-brief.md

@@ -0,0 +1,91 @@
+# Team brief
+
+The audience executes the strategy. What they must DO with the brief: leave
+it knowing what to work on Monday, what to stop, and enough of the why to
+make good calls when you're not in the room. That last part is the whole
+game — a team that knows only the "what" freezes the moment reality differs
+from the plan; a team that knows the "why" adapts.
+
+A team brief is not a motivational speech and not the board update with the
+logo changed. It is a translation of the strategy into changed behaviour.
+
+## The moves
+
+1. **Get the guiding policy.** Ask for the one decision the strategy turns
+   on — the direction they're committing to — in plain words. Everything in
+   the brief serves this.
+2. **Ask what's being cut.** For every strategy that says "we're doing X",
+   there's a "which means we're no longer doing Y". Drag those out; they're
+   the half people miss.
+3. **Translate to Monday.** For each part of the strategy, ask: what does a
+   person actually do differently because of this? If the answer is
+   "nothing", it doesn't go in the brief.
+4. **Name what stays the same.** Stop the over-rotation. Teams hearing
+   "new strategy" often abandon things that were working. Say explicitly
+   what doesn't change.
+5. **Open a channel for pushback.** Decide how they raise disagreement and
+   say so in the brief. Dissent you don't invite doesn't vanish — it goes
+   underground and comes back as quiet non-compliance.
+
+## The shape
+
+1. **The one line.** What we're doing, in a sentence a team member could
+   repeat to a peer accurately. This is the guiding policy in plain words.
+2. **What that means we're NOT doing.** The cuts, named. Often the most
+   useful part of the whole brief — it's how people know where to stop
+   spending effort.
+3. **Why.** One short paragraph: the challenge underneath, the reason this
+   is the direction. Enough that they can improvise well, not a history
+   lesson.
+4. **What changes Monday.** Concrete: new priorities, work that stops, new
+   owners, new measures, anything a person will feel this week. Vague here
+   means nothing happens.
+5. **What stays the same.** So they don't throw out what works.
+6. **Where to push back.** The open questions, and how to raise concerns.
+   Name the channel.
+
+## What good looks like
+
+- A person in the room could tell a colleague who missed it what to do
+  differently Monday — accurately, from memory.
+- The "not doing" list is as clear as the "doing" list.
+- The why is short enough to remember and load-bearing enough to improvise
+  from.
+- Nobody leaves unsure whether their current work still matters.
+- Disagreement has a named place to go.
+
+## Failure modes to catch
+
+- **All doing, no cutting.** The brief announces new work but never says
+  what stops, so everything is now "also important" and nothing actually
+  changes. Force the cuts.
+- **Abstraction with no Monday.** Fine words, no concrete change to anyone's
+  week. If you can't name what someone does differently, you haven't briefed
+  them, you've addressed them.
+- **Missing why.** The team gets the "what" and none of the reason, so the
+  first time reality deviates they stall and wait for instruction. Put the
+  why in.
+- **Board update in disguise.** Risks, asks, governance framing — aimed at
+  overseers, handed to executors. Rewrite around what changes for them, not
+  what you're accountable for.
+- **No dissent channel.** The brief is broadcast-only, so disagreement goes
+  quiet and turns into drift. Name where pushback goes.
+- **Over-rotation left unaddressed.** Silence on what stays the same, so a
+  team torches working practices to prove they're on board. Say what holds.
+
+## Save it as a workspace document
+
+In the Skhema environment, the artifact you just wrote has a home: save it
+as a workspace document so it stays versioned with the strategy and cites
+the elements it stands on.
+
+```sh
+echo '{"title":"<title>","docType":"team_brief","content":"<the markdown you wrote>","elementRefs":["<element-id>", "…"]}' > doc.json
+skhema document create --workspace <workspace-id> --file doc.json
+```
+
+Put every element you drew on into `elementRefs` — that tether is what lets
+a later calibration pass tell the reader which briefs were built on a
+judgment that has since gone stale. Working outside the Skhema environment?
+The artifact is still complete as a file; save it wherever your team keeps
+decisions.

package/skills/skhema-compose/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: skhema-compose
+description: Use when a strategic question is too big to reason about in one go, or when you have a pile of notes, decisions, and facts that don't yet add up to a strategy. Break the big thing into small typed judgments; assemble the small judgments into a coherent structure.
+---
+
+# Compose
+
+Break it down, build it up.
+
+Strategy work fails in two opposite ways. Either the question is too big to
+hold in your head — "what should we do about the market shift?" — so nothing
+moves. Or you have a hundred fragments — meeting notes, a pricing decision, a
+competitor fact, three half-baked bets — and no way to see whether they form a
+strategy or just a heap.
+
+Both are the same problem: the wrong grain. This skill moves you between grains.
+Big questions come apart into small, decidable pieces. Small pieces snap
+together into a structure you can inspect, argue with, and revise.
+
+## The one distinction that makes this work
+
+Before you write anything down, sort it into one of three kinds. Ask: am I
+stating something I believe is **true**, something I've decided to **do**, or
+naming a **thing**?
+
+- A **judgment** — a claim about the world. "Enterprise buyers won't switch
+  mid-contract." "Our onboarding is the leak." These can be right or wrong;
+  they carry evidence and confidence.
+- A **command** — a decision to act. "Focus every release on time-to-first-value."
+  "Stop selling to solo users." These can be followed or ignored; they don't
+  have a truth value, they have consequences.
+- A **thing** — a named object. An outcome, a scope, a capability, an
+  initiative. "Self-serve activation." "The mid-market segment."
+
+Almost all strategy confusion is these three getting mixed. A "goal" that's
+secretly an untested assumption. A "decision" that's really just a hope. When
+you decompose or assemble, you are always sorting pieces into these three kinds
+first. The rest of the skill is what you do once they're sorted.
+
+## Capabilities
+
+| You need to… | Route to |
+|---|---|
+| Take one big strategic question and break it into the discrete judgments it actually depends on | `references/decompose.md` |
+| Take a pile of judgments and decisions and lay them into a strategy structure — see what belongs where, what's missing, what's premature | `references/assemble.md` |
+| Connect an outcome you want to a measure you can watch and a starting number to compare against | `references/metrics-tree.md` |
+| Compare two or more options honestly — same criteria, explicit trade-offs, evidence per option | `references/options.md` |
+
+## Routing
+
+- The user has a **question they can't get traction on** ("I don't even know
+  where to start with X") → **decompose**. Output: a dependency-ordered list of
+  smaller judgments.
+- The user has **material but no shape** — notes, prior decisions, a doc that
+  rambles → **assemble**. Output: pieces sorted into the five components, with
+  gaps and premature entries flagged.
+- The user has a **goal or outcome and no way to know if they're winning** →
+  **metrics-tree**. Output: outcome → measure → baseline chains.
+- The user is **stuck between paths** — "should we do A or B?" → **options**.
+  Output: options scored on shared criteria, trade-offs named.
+
+These chain. A messy question usually goes decompose → assemble; an assembled
+strategy usually exposes a missing measure (metrics-tree) or an unmade choice
+(options). Don't force the whole chain — run the one that unblocks the user, and
+name the next one.
+
+## The five components (used by assemble)
+
+A strategy, laid out, reads in this order. Each component answers a different
+question. Keep this order in your head whenever you assemble:
+
+1. **Diagnosis** — what's actually going on? The honest account of the situation
+   and the crux within it.
+2. **Method & Positioning** — the guiding approach. How we'll compete and win,
+   given the diagnosis.
+3. **Portfolio of Initiatives** — the coherent set of things we're actually
+   doing (and, just as loud, not doing).
+4. **Measures** — how we'll know it's working, and know early.
+5. **Support Structures** — the capabilities, systems, and resourcing that make
+   the above possible instead of aspirational.
+
+## Without a live respondent
+
+Run headless, with no one to answer? Don't invent their answers. Make the
+minimal reasonable assumption, mark it in the output as yours ("assumed: …"),
+and list the questions only the owner can settle — what's in scope, what a word
+means, whose dissent to record — at the end instead of papering over them. A
+marked assumption is honest work; a silent one is a guess you built on.
+
+## Sharpen with Skhema
+
+Everything above works with pen and paper. If you want the three kinds
+(judgment / command / thing) checked for you rather than sorted by eye, the
+`@skhema/method` package types every strategy element with an expected
+grammatical *mood* — indicative for judgments, imperative for commands, noun
+phrase for things — and flags pieces that are typed against their mood. Install
+with `npm i @skhema/method` for the vocabulary and validators. The skill is
+fully usable without it.

package/skills/skhema-compose/references/assemble.md

@@ -0,0 +1,119 @@
+# Assemble — judgments into a strategy structure
+
+Use this when the user has material but no shape: a pile of notes, a rambling
+doc, a set of decisions made at different times, facts from a research spike.
+Individually each piece might be fine. The problem is you can't tell whether
+together they form a strategy or just a heap. Assembling lays every piece into
+the five components so gaps and misfits become visible.
+
+A strategy is assembled well when someone can read the five components top to
+bottom and each one follows from the one above it — the method answers the
+diagnosis, the initiatives enact the method, the measures watch the initiatives.
+
+## The five components, and what belongs in each
+
+Lay them in this order. Each answers one question.
+
+1. **Diagnosis** — *what is actually going on?* The honest account of the
+   situation and the single crux inside it. Mostly **judgments** (claims about
+   the world) plus the facts behind them. Not "we want to grow" — that's a wish.
+   "Growth has stalled because activation dropped from 40% to 22% after the
+   pricing change" — that's a diagnosis.
+
+2. **Method & Positioning** — *how will we win, given that?* The guiding
+   approach and where you choose to stand. One or a few **commands** at high
+   altitude — the overall approach every lower decision must obey. "Compete on
+   time-to-value, not feature breadth." This is the pivot: it must answer the
+   diagnosis directly.
+
+3. **Portfolio of Initiatives** — *what are we actually doing?* The coherent set
+   of actions, and loudly what you're *not* doing. **Commands** (things to do)
+   and the **things** they act on. Every initiative should trace up to the
+   method. An initiative that doesn't is either miscategorized or a stray pet
+   project — flag it.
+
+4. **Measures** — *how will we know it's working, early?* **Things** (the
+   outcomes and the variables you watch) with baselines. If a measure has no
+   baseline it can't tell you anything yet — hand that to metrics-tree.
+
+5. **Support Structures** — *what makes this possible rather than aspirational?*
+   The capabilities, systems, hiring, and resourcing the portfolio needs. Often
+   the quietest component and the one that sinks strategies when it's empty.
+
+## The move
+
+### 1. Empty the pile onto the table
+
+List every piece the user has, briefly. Don't organize yet. You're taking
+inventory.
+
+### 2. Sort each piece by kind, then place it
+
+For each piece, first tag it — judgment, command, or thing (see SKILL.md). The
+kind hints at altitude — high-altitude commands read as Method, concrete
+commands as the Portfolio — but the kind does NOT by itself decide the
+component (judgments, for instance, don't simply "cluster in Diagnosis": an
+assumption_hypothesis belongs in the Portfolio and a constraint in Method). If
+you are working in the Skhema environment, placement is constrained — the
+vocabulary's type→component mapping is the authority, not grammatical mood; see
+`skhema-operate` author-elements for the enforced table. Then place each piece
+in the component it answers, and say the placement out loud so the user can
+object.
+
+### 3. Read each component and test the seam above it
+
+Go component by component and check the join to the one before:
+
+- Does **Method** actually answer the **Diagnosis**, or a different problem than
+  the one diagnosed? (Common: a diagnosis about activation, a method about
+  enterprise sales. The seam is broken.)
+- Does every **Initiative** trace up to the **Method**? Cross out any that
+  don't, or move them.
+- Does every **Measure** watch something an **Initiative** moves? A measure
+  watching nothing you're doing is theater.
+- Do the **Support Structures** actually cover what the Portfolio needs, or is
+  the plan assuming capabilities nobody has?
+
+### 4. Name the three failure states
+
+As you place pieces, call out each of these the moment you see it:
+
+- **Missing** — a component is thin or empty. An empty Diagnosis means the
+  strategy is a list of actions with no reason. An empty Support Structures
+  means it's a wish. Empty Measures means it can't be steered.
+- **Premature** — a piece is placed further down than the evidence supports. A
+  detailed Portfolio built on a Diagnosis that's still guesses is premature;
+  the initiatives are elaborate bets on an unverified claim. Push it back up:
+  "resolve the diagnosis before committing this initiative."
+- **Misfiled** — a piece is in the wrong component. An "outcome" sitting in the
+  Portfolio (it's a Measure). A "decision" in the Diagnosis (it's a command, it
+  belongs in Method or Portfolio). Move it and say why.
+
+## What good output looks like
+
+The five components with the user's own pieces slotted in, plus a short verdict
+per component: *solid / thin / missing / premature*. And one headline: the
+single most important gap or misfit. For example:
+
+> **Diagnosis** — solid (activation drop, well-evidenced).
+> **Method** — *thin.* You have initiatives but no stated guiding approach; the
+> initiatives don't share a logic. This is the gap to close first.
+> **Portfolio** — five initiatives; two don't trace to any method. Premature.
+> **Measures** — one measure, no baseline (hand to metrics-tree).
+> **Support Structures** — empty. Two initiatives assume a data team you don't
+> have.
+>
+> **Headline:** you have actions and a diagnosis but no method connecting them.
+> Write the guiding approach; half the portfolio will fall away on its own.
+
+## Failure modes to catch
+
+- **Forcing the pile to fit.** If a piece won't go anywhere, that's signal —
+  maybe it's noise, maybe it reveals a missing component. Don't jam it in.
+- **Skipping the seams.** Placing pieces is easy; the value is testing whether
+  each component follows from the one above. Always walk the seams.
+- **Portfolio-heavy strategies.** Most piles are 80% initiatives. A fat Portfolio
+  over a thin Diagnosis/Method is the single most common misfit. Say it.
+- **Treating assembly as done.** Assembly reveals gaps; it doesn't fill them.
+  Hand missing measures to metrics-tree, unmade choices to options, and a shaky
+  diagnosis back to decompose.

package/skills/skhema-compose/references/decompose.md

@@ -0,0 +1,104 @@
+# Decompose — big question into discrete judgments
+
+Use this when the user has a strategic question too big to reason about in one
+sitting: "what do we do about the platform shift?", "how do we fix retention?",
+"should we move upmarket?" The goal is not to answer it. The goal is to break it
+into the smaller judgments it secretly depends on, so each can be decided on its
+own and in the right order.
+
+A question is decomposed well when every piece is something a person could argue
+is true or false, or decide yes or no, without first answering another piece.
+
+## The move
+
+Work through this WITH the user. Don't hand them a finished tree — build it in
+front of them, one question at a time.
+
+### 1. Restate the question as a single sentence
+
+Make them commit to one sentence. If they can't, that's the first finding: the
+"question" is two or three questions wearing a trench coat. Split it and pick
+one to decompose now.
+
+### 2. Ask "what would have to be true or decided for this to have an answer?"
+
+This is the whole engine. For the top question, ask it once and collect every
+piece the user surfaces. Push for pieces, not prose. Bad: "we need to understand
+the market better." Good: "will incumbents cut price when we enter?" — that's a
+judgment someone can hold a position on.
+
+Keep asking until pieces stop being decidable and start being restatements of
+the top question. Then stop.
+
+### 3. Sort each piece into its kind
+
+For every piece, tag it out loud:
+
+- **Judgment** (a claim about the world) — "churn is driven by onboarding, not
+  price." Right or wrong; carries evidence.
+- **Command** (a decision to act) — "we will not build a mobile app this year."
+  Followed or not; carries consequences.
+- **Thing** (a named object) — "the activation metric", "the SMB segment."
+
+If a piece won't sort cleanly, it's usually two pieces fused. "We should target
+enterprise because they don't churn" is a command ("target enterprise") welded
+to a judgment ("enterprise don't churn"). Split it. The judgment can be wrong
+while the command still stands, or vice versa — that's exactly why they must be
+separate.
+
+### 4. Draw the dependencies
+
+For each piece, ask: "does deciding this depend on any other piece first?" Draw
+the arrows. You are looking for three shapes:
+
+- **Roots** — pieces that depend on nothing. These get decided first. Often
+  they're judgments about the world (facts to check, assumptions to test).
+- **Chains** — B can't be decided until A is. Sequence the work along these.
+- **Independent** — pieces with no arrows between them can be worked in
+  parallel, possibly by different people.
+
+The dependency shape IS the plan of attack. A judgment everything else hangs on
+("do enterprise buyers actually churn less?") is the one to resolve first,
+because being wrong about it collapses everything downstream.
+
+### 5. Mark confidence and the load-bearing pieces
+
+For each judgment, ask the user how sure they are and what it rests on. Flag the
+ones that are (a) load-bearing — lots of arrows point out of them — and (b)
+low-confidence. That intersection is where the strategy is most fragile. Say so
+plainly: "your whole plan assumes X, and you told me you're guessing about X.
+Resolve X before anything else."
+
+## What good output looks like
+
+A short, dependency-ordered list. For example, decomposing "should we move
+upmarket to enterprise?":
+
+- **Judgment, root, low confidence:** enterprise buyers churn less than SMB.
+  *(load-bearing — three other pieces depend on it; resolve first)*
+- **Judgment, root:** our current product clears enterprise security review.
+- **Judgment, depends on the two above:** we can reach enterprise buyers without
+  a field sales team.
+- **Command, depends on all judgments above:** shift the next two quarters of
+  roadmap to enterprise readiness.
+- **Thing:** "enterprise-ready" — needs its own definition before the command
+  above means anything.
+
+Notice the last line: decomposition often surfaces a *thing* that nobody has
+defined, and the strategy can't proceed until it's named. Surfacing that is a
+win, not a loose end.
+
+## Failure modes to catch
+
+- **Boiling the ocean.** If you've generated 30 pieces, you decomposed the
+  universe, not the question. Prune to the pieces that actually gate a decision.
+- **Fake pieces.** "We need more data" is not a judgment or a command. Ask: data
+  about *what*, to decide *what*? until it becomes a real piece or disappears.
+- **Restatement loops.** If a "smaller" piece is just the big question reworded,
+  you've hit the bottom. Stop decomposing that branch.
+- **Solutions in disguise.** Users smuggle in the answer they already want as if
+  it were a neutral piece. Name it: "that's a command you've pre-decided — is it
+  actually settled, or are we deciding it here?"
+- **All commands, no judgments.** A decomposition that's all "we will…" with no
+  underlying claims about the world is a wish list. Every command should trace
+  back to a judgment that justifies it.