@skhema/cli 0.4.4 → 0.4.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skhema/cli",
-  "version": "0.4.4",
+  "version": "0.4.5",
   "description": "Skhema CLI - Authentication and AI skills management for agent platforms",
   "type": "module",
   "main": "dist/index.js",

package/skills/.manifest.json

@@ -1,15 +1,13 @@
 {
-  "syncedAt": "2026-07-09T00:27:14.921Z",
+  "syncedAt": "2026-07-09T17:15:20.908Z",
   "source": "/Users/michaellovell/Desktop/GitHub/skhema-skills",
-  "sourceSha": "77561c7dbde8602ca799e5224c65ea18675ee37b",
+  "sourceSha": "2a3abbb24f2fb2539608102eabc90de10fc9984b",
   "skills": [
-    "skhema-challenge-framing",
-    "skhema-coherence-check",
-    "skhema-element-decomposition",
-    "skhema-element-writer",
-    "skhema-judgment-audit",
-    "skhema-semantic-sharpening",
-    "skhema-strategy-advisor",
-    "skhema-workspace-navigator"
+    "skhema-frame",
+    "skhema-compose",
+    "skhema-calibrate",
+    "skhema-pressure-test",
+    "skhema-communicate",
+    "skhema-operate"
   ]
 }

package/skills/skhema-calibrate/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: skhema-calibrate
+description: "Use when you already have a strategy (or a piece of one) written down and need to check it still holds up — spot internal contradictions, claims resting on nothing, words that mean different things to different readers, or judgments the world has since overtaken. A self-check, not an attack; for an adversarial interrogation, use skhema-pressure-test."
+---
+
+# Calibrate
+
+You have something written. A strategy, a plan, a decision memo, a page of it.
+This skill checks whether it is still sound and still current. Not to tear it
+down — to true it up, like checking a level before you build on it.
+
+Calibration is a self-check you run WITH the person on their own work. You read
+what they wrote, you point at specific lines, you ask specific questions. The
+output is a short list of concrete problems, each tied to a place in the text,
+each with a fix or a question that surfaces the fix.
+
+This is not brainstorming and not interrogation. If the person wants their
+strategy attacked from the outside — a devil's-advocate grilling, a pre-mortem —
+that is **skhema-pressure-test**, a different skill. Calibrate stays inside the
+document and asks: does this agree with itself, does it rest on real evidence,
+does it say one clear thing, and is it still true today?
+
+## The four checks
+
+Run whichever the situation calls for. On a full review, run all four in this
+order — each surfaces different faults, and later checks are cleaner once the
+earlier ones are fixed.
+
+| Check | You are hunting for | Route to |
+|---|---|---|
+| Coherence | Two parts that disagree, a tension nobody named, a decision with no follow-through | `references/coherence.md` |
+| Assumptions | Claims stated as fact that are really beliefs; confidence that outruns the evidence | `references/assumptions.md` |
+| Language | Words vague enough that two readers walk away believing different things | `references/language.md` |
+| Freshness | Judgments made under conditions that no longer hold; facts that have gone stale | `references/freshness.md` |
+
+## How to pick
+
+- "Does this hang together?" / "something feels off but I can't say what" /
+  "we decided X here and Y there" → **coherence**.
+- "How sure are we?" / "is this actually true or do we just think so?" /
+  before committing real money or people → **assumptions**.
+- "Everyone read this and nodded but we're doing different things" /
+  "what does 'scale' even mean here" → **language**.
+- "This was written months ago" / "the market moved" / "is this still our
+  situation?" → **freshness**.
+
+If they just say "review this" or "is this any good?", run all four. Announce
+which you're doing as you go so they can follow.
+
+## One habit that runs through all four
+
+Every line in a strategy is doing one of three jobs. Before you judge a line,
+know which:
+
+- **A claim about the world** — something believed true. "Enterprise buyers
+  won't self-serve." These get the assumptions check: what's the evidence?
+- **A command** — something decided to do. "Ship the free tier first." These
+  get the coherence check: does the rest of the plan act on it?
+- **A named thing** — a scope, an outcome, a solution. "The onboarding flow."
+  These get the language check: would two readers point at the same thing?
+
+Most calibration faults are one of these three lines wearing another's clothes:
+a belief written as if it were a decided fact, a hope written as if it were a
+measurable outcome. Naming the job first makes the fault obvious.
+
+## What good output looks like
+
+Not "the strategy has some inconsistencies." Instead: a numbered list where
+each item quotes the exact line, names the fault, and gives the fix or the
+question that gets there. Three sharp findings the person acts on beat twenty
+vague ones they ignore. If a section is clean, say so and move on — do not
+manufacture problems to look thorough.
+
+## 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
+
+These checks work on any document, in any editor, with nothing installed. If you
+want them automated — every claim typed by its job (world-claim vs command vs
+thing), contradictions flagged as you write, staleness dated — the Skhema method
+gives each strategy element a typed structure the checks run against. Start with
+`npm i @skhema/method` for the vocabulary and validators, or run them in a Skhema
+workspace where the four checks are wired into the element itself. Optional: the
+skill is complete without it.

package/skills/skhema-calibrate/references/assumptions.md

@@ -0,0 +1,77 @@
+# Assumptions
+
+Every strategy rests on things believed true. Some are backed by evidence. Some
+are guesses wearing the clothes of fact. This check separates them, so nobody
+bets real money or people on a sentence that only sounds certain.
+
+The core move: take each claim about the world and ask one blunt question —
+**what is the evidence?** A claim with good evidence is a fact you can lean on. A
+claim with none is an assumption, and it gets labelled as one. That is the whole
+job: type every claim, then look at what you're standing on.
+
+## Find the claims
+
+Walk the strategy and pull every line that states something about the world as
+true. These are the "claims about the world" — the beliefs, not the decisions or
+the named things. Signs of a claim: "customers want", "the market is",
+"competitors can't", "this will grow", "nobody else", "it's too expensive to".
+
+Skip the commands ("ship X") and the labels ("the growth team") — those get
+other checks. You want the load-bearing beliefs, because those are what the
+decisions rest on.
+
+## Type each claim
+
+For every claim, ask for the evidence behind it, then sort it into one bucket:
+
+- **Fact** — direct evidence you can point at. Data, a documented result, a
+  signed contract, a thing you measured. "Churn is 4% monthly" and here's the
+  dashboard.
+- **Assumption** — believed, not shown. No evidence, or only "it stands to
+  reason." "Enterprise buyers won't self-serve." Maybe true. Not demonstrated.
+- **Inference** — reasoned from a fact, but a step removed. "Churn is 4%, so
+  buyers don't see the value." The 4% is a fact; the *why* is a guess dressed as
+  a conclusion. Flag the guess.
+
+The forcing question for each: *if someone asked "how do we know?", what would
+you show them?* If the honest answer is "we don't, we think so" — it's an
+assumption. Label it. There is no shame in an assumption; there is danger in a
+mislabelled one.
+
+## Rate the confidence, and check it earns its weight
+
+Two things matter about each claim, and people conflate them:
+
+- **How sure are we?** High / medium / low, based on evidence quality.
+- **How much rests on it?** If this claim is wrong, how much of the strategy
+  falls?
+
+Plot them against each other. The claims that matter are **load-bearing and
+low-confidence** — high stakes, weak evidence. Those are the ones to name out
+loud and, ideally, turn into something testable before committing. A shaky
+assumption nothing depends on can stay shaky. A shaky assumption the whole plan
+stands on is the real finding of this whole exercise.
+
+Also watch for **confidence that outruns the evidence**: language like
+"obviously", "clearly", "everyone knows", "of course". Certainty in the wording
+is not certainty in the world. The louder the claim, the harder you check it.
+
+## Output
+
+A table or numbered list, one row per claim: the claim quoted, its type (fact /
+assumption / inference), confidence (high / med / low), and how load-bearing it
+is. Then a short verdict that pulls out the two or three load-bearing,
+low-confidence claims and says plainly: *these are what the strategy is really
+betting on; here is what would raise our confidence.*
+
+## Failure modes to avoid
+
+- **Letting "obviously" pass.** The words that most need checking are the ones
+  that sound like they don't.
+- **Rating confidence without asking for evidence.** Confidence is an output of
+  evidence, not a vibe. Always ask "how do we know?" first.
+- **Treating every assumption as a problem.** The goal is to type them, not
+  eliminate them. Strategy runs on assumptions. The point is knowing which ones,
+  and which ones are load-bearing.
+- **Missing the inferences.** These are the sneakiest — a real fact with a guess
+  bolted on, presented as one solid claim. Split them.

package/skills/skhema-calibrate/references/coherence.md

@@ -0,0 +1,95 @@
+# Coherence
+
+Does the strategy agree with itself? You are hunting for three faults:
+**contradictions** (two parts that can't both be acted on), **unnamed tensions**
+(two parts that pull against each other and nobody said so), and **gaps** (a
+decision with no follow-through, or a goal with nothing aimed at it).
+
+Coherence is never automatic. A strategy is written in pieces, over time, by
+people in different moods. The pieces drift. Your job is to lay them side by side
+and find where they stop fitting.
+
+## Before you start
+
+Get the whole thing in front of you. Coherence can only be checked across the
+full set — a single element in isolation always looks fine. If they hand you one
+page, ask what it connects to: what decision it serves, what it depends on.
+
+## The moves
+
+Run these in order. Each pass looks for one fault type.
+
+### 1. List the commitments
+
+Read through and pull out every line that commits to something — a decision, a
+priority, a target, a "we will" or "we won't." Write them as a flat numbered
+list, in the person's own words. This list is your working surface; you check it
+against itself, not the prose.
+
+### 2. Hunt contradictions
+
+Go down the list and, for each commitment, ask: is there another commitment it
+can't coexist with? Watch for:
+
+- **Resource collisions.** "Move fast on A" and "move fast on B" when A and B
+  draw on the same one team. Two top priorities is zero priorities — say so.
+- **Direction collisions.** "Premium positioning" and "win on price." Both may
+  be written proudly, pages apart.
+- **Sequence collisions.** "B depends on A" but the plan does B first.
+
+For each hit, quote both lines and state the collision in one sentence. Do not
+resolve it yourself — that is the person's call. Surface it and ask which gives.
+
+### 3. Name the tensions
+
+A tension is softer than a contradiction: both parts can survive, but they pull
+opposite ways and the strain is unmanaged. "Serve enterprise and stay
+self-serve." Often fine — but only if named, because an unnamed tension gets
+resolved by accident, differently by each person, under pressure.
+
+For each tension: name it, say which two commitments create it, and ask the one
+question that matters — *is this a deliberate balance you're holding, or a
+choice you haven't made yet?* A named tension is a feature. An unnamed one is a
+future argument.
+
+### 4. Find the gaps
+
+Two directions:
+
+- **Decisions with no follow-through.** A commitment that nothing downstream
+  acts on. "We'll win on service" — then no line about staffing, training, or a
+  service metric. The decision is decoration until something carries it.
+- **Goals with nothing aimed at them.** An outcome or target that no initiative,
+  action, or resource points at. Ask: what in this plan actually moves that
+  number?
+
+Gaps hide because absence is invisible. You find them by walking each commitment
+forward ("what happens because of this?") and each goal backward ("what here
+causes this?") and noting where the trail goes cold.
+
+### 5. Spot the off-topic orphan
+
+Sometimes a piece shares no subject with the rest — it's about a different
+market, product, or problem entirely. It can't contradict, support, or gap
+anything, because it isn't part of this argument at all. That's not a coherence
+fault to resolve; it's a sign the element belongs to a *different strategy*.
+Flag it, say what it seems to be about, and recommend it move to its own
+workspace. Never delete it yourself — it may be someone else's live work,
+misfiled here.
+
+## Output
+
+A numbered list. Each item: the fault type (contradiction / tension / gap), the
+exact line(s) quoted, one sentence of what's wrong, and either the fix or the
+question that forces the fix. Group by type. If the set is coherent, say which
+tensions you checked and confirmed are named — that is a real finding too.
+
+## Failure modes to avoid
+
+- **Manufacturing contradictions from vague words.** If two lines only clash
+  because a word is fuzzy, that's a language problem, not a coherence one — route
+  it to `language.md`, don't dress it up as a contradiction.
+- **Resolving it for them.** You flag, they choose. Picking the winner yourself
+  skips the judgment that is theirs to make.
+- **Stopping at the first find.** Walk the whole list. The expensive
+  contradiction is usually not the obvious one.

package/skills/skhema-calibrate/references/freshness.md

@@ -0,0 +1,81 @@
+# Freshness
+
+A strategy is a set of judgments made at a moment, under conditions that were
+true then. Time passes. The conditions move. Some judgments that were right are
+now stale — not wrong when written, just overtaken. This check finds them before
+you keep building on ground that shifted.
+
+The move: for each judgment, recover the conditions it was made under, then ask
+*do those conditions still hold?* Where they don't, the judgment is up for
+re-decision. You are not attacking the old call. You are checking whether the
+world it assumed is still the world you're in.
+
+## Anchor the date
+
+Find out when the strategy — or the part you're checking — was written or last
+reviewed. If it isn't dated, that is itself a finding: an undated strategy can't
+be kept fresh, because nobody knows how old any judgment is. Establish a rough
+date before you go further, from the person or from context.
+
+## Surface the conditions behind each judgment
+
+Walk the load-bearing decisions and claims. For each, ask: *what had to be true
+about the world for this to be the right call?* Make the hidden conditions
+explicit. Examples:
+
+- "Build our own billing" assumed no good off-the-shelf option existed **then**.
+- "Don't invest in mobile" assumed usage was desktop-first **then**.
+- "Price at $X" assumed a competitor set at $Y and a cost base of $Z **then**.
+- "Win on being AI-native" assumed rivals weren't **then**.
+
+Most conditions are unstated. The judgment records the conclusion, not the world
+it depended on. Your value is reconstructing that world so you can check it.
+
+## Check what moved
+
+For each condition, ask what has changed since the anchor date. Sweep the usual
+sources of drift:
+
+- **Competitors** — new entrants, a rival that closed the gap, someone who
+  exited.
+- **The market** — demand shifted, a segment grew or died, buyer behaviour
+  changed.
+- **Technology** — a capability that was hard or impossible is now cheap and
+  routine (this one dates strategies fastest).
+- **Your own position** — you have people, money, data, or a product you didn't
+  have then. Constraints that shaped the old call may be gone.
+- **Regulation / platform / external rules** — a policy, a fee, a dependency
+  changed under you.
+
+Where a condition held then and doesn't now, flag the judgment that rode on it.
+
+## Rate the staleness
+
+Not every changed condition matters. Sort each flagged judgment:
+
+- **Stale and load-bearing** — the condition moved AND a lot rests on this
+  judgment. Re-decide now. This is the finding that justifies the whole check.
+- **Stale but minor** — overtaken, but little depends on it. Note it, move on.
+- **Still current** — conditions hold. Say so; confirmed-fresh is a real result
+  and stops needless churn.
+
+## Output
+
+A numbered list: the judgment quoted, the condition it rested on, what changed,
+and the verdict (re-decide now / note / still holds). Lead with the stale-and-
+load-bearing ones. If the strategy is undated, say that first — it's the root
+cause that makes everything else guesswork.
+
+## Failure modes to avoid
+
+- **Re-litigating good calls.** A judgment made under conditions that STILL hold
+  is not stale, even if it's old. Age alone is not the fault; a moved condition
+  is. Don't reopen settled decisions for the sake of it.
+- **Only checking the outside world.** The biggest change is often *your own*
+  position — new capability, new resources. A constraint that forced the old
+  call may simply be gone.
+- **Missing the tech shift.** "It was too expensive to build" ages fastest of
+  all. Always ask whether the hard thing got cheap.
+- **Confusing stale with wrong.** Freshness is about conditions changing, not
+  about the original call being a mistake. Frame it as "time overtook this", not
+  "this was bad" — that keeps the person willing to re-decide honestly.

package/skills/skhema-calibrate/references/language.md

@@ -0,0 +1,74 @@
+# Language
+
+Some words let two readers walk away believing different things. Everyone nods
+at the meeting; then they go and do different work, each sure they're following
+the plan. This check hunts those words down and forces one shared meaning.
+
+The move is simple and slightly adversarial toward the text: for each fuzzy
+word, ask *could two reasonable people read this and picture different things?*
+If yes, it's a leak. You plug it by making the person say exactly what they mean,
+then writing that back into the line.
+
+## The words to hunt
+
+Read the strategy slowly and stop on any word that sounds like agreement but
+carries no fixed meaning. The usual suspects:
+
+- **Scale words** — "scale", "grow", "significant", "meaningful". Grow to what,
+  by when, measured how?
+- **Quality words** — "best-in-class", "world-class", "seamless", "delightful",
+  "robust". By whose standard? Shown how?
+- **Direction words** — "leverage", "optimize", "streamline", "double down",
+  "focus on". These describe motion without saying the actual action.
+- **Boundary words** — "soon", "some", "most", "enterprise", "the market",
+  "power users". Which ones exactly? Where's the line?
+- **Weasel qualifiers** — "essentially", "basically", "kind of", "where
+  appropriate", "as needed". These smuggle in an escape hatch. Whose judgment
+  fills the blank, and when?
+
+A fast test: could you hold this word to account in six months? "We'll grow" —
+you can never be wrong. "We'll reach 500 paying teams by Q3" — you can. Words you
+can't be wrong about are words that aren't saying anything.
+
+## The move, per word
+
+1. **Point at it.** Quote the line, underline the word.
+2. **Ask the question that exposes the fork.** Not "what do you mean?" — too
+   open. Ask the specific one: "scale to how many?", "seamless compared to
+   what?", "which customers count as enterprise — draw me the line." Make them
+   commit to a number, a name, or a test.
+3. **Watch for the tell.** If they answer instantly and precisely, the word was
+   just shorthand — fine, tighten it and move on. If they pause, or two people
+   in the room answer differently, you found a real one. The disagreement in
+   the room IS the finding.
+4. **Rewrite the line** with the precise meaning in place. "Improve onboarding"
+   becomes "get a new user to their first saved element in under five minutes."
+   Now it can be built, and it can be checked.
+
+## A special catch: the same word, two meanings
+
+Worse than one vague word is one word used two ways in the same document.
+"Platform" meaning the tech in one section and the business model in another.
+"Customer" meaning the buyer here and the end-user there. Scan for repeated
+key terms and confirm each use points at the same thing. When it doesn't, either
+split the word into two, or pick one meaning and enforce it throughout.
+
+## Output
+
+A numbered list: the vague term, the line it's in, the fork (the two+ things it
+could mean), and the sharpened rewrite — or the question still open if the person
+needs to decide. End with any word-used-two-ways findings called out separately,
+since those cause the most expensive confusion.
+
+## Failure modes to avoid
+
+- **Sharpening words that don't carry weight.** Not every adjective needs a
+  ruler. Target the words that decisions and accountability hang on. Fuzz in a
+  throwaay line is fine; fuzz in the goal is not.
+- **Accepting a synonym as a definition.** "By seamless we mean frictionless" is
+  not a definition. Push until you get a test, a number, or a concrete example.
+- **Doing the deciding.** If "enterprise" has no line drawn, you don't draw it —
+  you make them draw it. The vagueness is often hiding a decision they haven't
+  made. Surface that; don't paper over it.
+- **Confusing this with coherence.** If the problem is two lines disagreeing,
+  that's `coherence.md`. Here the problem is one line meaning two things.

package/skills/skhema-communicate/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: skhema-communicate
+description: "Use when a strategy already exists and now has to move to people who didn't build it — a board, a team, a new hire, an investor. Packages the same strategy at the right resolution for each audience: a board update, a team brief, a one-page decision brief, or an adaptation pass across several audiences at once."
+---
+
+# Communicate
+
+The strategy exists. Now it has to move — to a board that oversees it, a
+team that executes it, a new hire who inherits it, an investor who funds
+it. Your job is not to re-decide the strategy or improve it. Your job is
+to make the same strategy land with people who will each do something
+different with it.
+
+There is one cardinal rule, and every capability here obeys it: **same
+strategy, different resolution — never a different strategy per audience.**
+A board sees less detail than a team, a new hire sees less than the board;
+none of them sees a version that contradicts another. The moment two
+audiences would disagree about what the strategy IS, you have stopped
+communicating and started spinning, and the credibility bill comes later.
+
+## The first move: who, and what must they DO with it?
+
+Before you write anything, answer two questions out loud:
+
+> **Who** is this for, and **what do they need to DO** with the strategy —
+> oversee it, execute it, sign off on one decision, or fund it?
+
+What they need to do decides what they see. An audience that oversees needs
+decisions, risks, and asks. An audience that executes needs to know what
+changes Monday morning. Someone signing off on one fork needs that one
+decision, not the whole strategy. Get the "what must they do" wrong and you
+hand a board a work plan or hand a team a governance report — both bounce.
+
+| The audience needs to… | Route to |
+|---|---|
+| Oversee and back the strategy — a board, a steering group, a governance body | `references/board-update.md` |
+| Execute it — the team or teams who will do the work | `references/team-brief.md` |
+| Sign off on, or record, one specific decision | `references/decision-brief.md` |
+| Several of the above at once, or you're unsure how much to show whom | `references/audience-adaptation.md` |
+
+## How to pick
+
+- They asked for "an update for the board / the investors / the leadership
+  group" — people who hold you accountable but don't do the work →
+  **board-update**. Decisions, evidence, risks, asks. No theatre.
+- They asked to "tell the team" or "roll this out" — the people who execute
+  → **team-brief**. What we're doing, what we're not, and what changes
+  Monday.
+- It's really about **one** choice — a build-or-buy, a hire, a shutdown —
+  that needs a yes and a paper trail → **decision-brief**. One decision,
+  one page.
+- There are multiple audiences, or the question is "how much do I tell
+  each of them" → **audience-adaptation** first. It sets the altitude for
+  each audience, then routes you into the others per audience.
+
+If you have several audiences, run **audience-adaptation** first — it keeps
+every downstream rendering coherent with the others. Then produce each
+artifact.
+
+## What "communicated" means
+
+A capability is done when the audience can act on the strategy without
+coming back to ask what it means — the board can vote on the asks, the team
+knows what to do Monday, the signer can say yes or no. And when you could
+read every version you produced aloud in one room without contradicting
+yourself. If a reader has to reconstruct the strategy from your words, you
+under-resolved. If two audiences would argue about what it says, you
+over-adapted. Each reference file gives you the shape for its audience and
+the failure modes to catch.
+
+## 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
+
+Communicating well is really re-resolving typed judgments for an audience:
+a board wants the decisions (the commands) and the risks (the assumptions
+still open); a team wants the guiding policy (a command) turned into
+actions. If your strategy is written as typed elements, you already know
+which pieces each audience needs — you're filtering by type, not
+rewriting. `npm i @skhema/method` gives you that typed vocabulary, so
+"what does the board see versus the team" becomes a filter over the same
+elements instead of a fresh draft you have to keep in sync by hand. You
+don't need it to run this skill — but it is what stops the board version
+and the team version from silently drifting apart.
+
+Every capability here ends by saving its artifact as a **workspace
+document** (`skhema document create`) — the narrative stays tethered to the
+elements it cites instead of dying in a chat log.

package/skills/skhema-communicate/references/audience-adaptation.md

@@ -0,0 +1,103 @@
+# Audience adaptation
+
+You have one strategy and several audiences — a board, a team, a new hire,
+an investor. This capability decides how much each of them sees, and keeps
+every version honest against the others. Run it first, before you produce
+any single artifact, whenever more than one audience is in play.
+
+The one rule that governs everything here: **same strategy, different
+resolution — never a different strategy per audience.** A board sees the
+decisions and the risks; a team sees what changes Monday; a new hire sees
+the through-line and where they fit. Those are different zoom levels on one
+map. They are not different maps. The instant two versions would contradict
+each other, you have two strategies and a credibility failure waiting to
+surface.
+
+## The moves
+
+1. **List the audiences.** Everyone who has to receive this strategy.
+2. **For each, ask what they must DO with it.** Decide, execute, fund,
+   join, comply? This is the whole basis for adaptation — not seniority,
+   not politeness. What they do determines what they need to see.
+3. **Set the altitude from the job.** Give each audience exactly the
+   resolution their job requires — no more (detail they can't act on is
+   noise), no less (missing what they need forces them to guess).
+4. **Pick the format per audience.** Route each to the right artifact:
+   board → `board-update.md`, team → `team-brief.md`, a single sign-off →
+   `decision-brief.md`. A new hire or an investor may need a custom one-pager
+   built on the same principle.
+5. **Run the coherence check** (below). This is the step that separates
+   adaptation from spin. Do not skip it.
+
+## Altitude by job
+
+| Audience | What they must do | What they see (resolution) |
+|---|---|---|
+| Board / investors | Oversee, back, fund | The decisions, the evidence, the risks carried, the asks |
+| Team | Execute | The guiding policy, what's cut, what changes Monday, the why |
+| New hire | Join and orient | The through-line, why it's the direction, where they fit |
+| Signer of one call | Approve one decision | That decision, its evidence, its reversibility |
+| Regulator / partner | Comply / rely on | The commitments that bind us, no internal deliberation |
+
+Same strategy underneath every row. Only the resolution changes.
+
+## The coherence check
+
+Line up every version you've produced and test them against each other:
+
+- **Every claim in the short version must be true in the long version.**
+  The new-hire one-liner is a compression of the board's decisions, not a
+  softer or bolder claim than them.
+- **No version may contradict another.** If the board hears "steady
+  progress" and the team hears "urgent turnaround", those aren't two
+  altitudes, they're two stories. Pick the true one and resolve both from
+  it.
+- **Differences are resolution, not substance.** Detail dropped for a higher
+  audience must be detail, never a different decision, a different risk
+  posture, or a different level of confidence.
+
+The test in one sentence: **could you put every audience in one room and
+read all your versions aloud without contradicting yourself?** If yes, you
+adapted. If you'd have to hope they never compare notes, you spun, and the
+comparison always eventually happens.
+
+## What good looks like
+
+- Each audience gets the altitude their job needs and no other.
+- The versions nest cleanly: zoom out from the team brief and you land on
+  the board update; zoom out again and you land on the through-line.
+- You would be comfortable if any audience saw any other's version.
+
+## Failure modes to catch
+
+- **Two stories.** Optimism for the board, alarm for the team, or vice
+  versa. One true account, resolved differently. Never two.
+- **Different decision per audience.** Telling one group you'll build and
+  another you might buy. That's not adaptation — the strategy itself is
+  moving. Fix the strategy, then communicate it.
+- **Flat resolution.** Everyone gets the same altitude, so the board drowns
+  in execution detail and the team gets strategic fog. Set altitude per
+  job.
+- **Tone-only adaptation.** You changed the warmth and the vocabulary but
+  gave every audience the same depth. Adapt the resolution, not just the
+  register.
+- **Skipping the coherence check.** Each version was written well in
+  isolation and never lined up against the others. Line them up; that is
+  where the drift shows.
+
+## 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|team_brief|decision_brief|custom>","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.