@skhema/cli 0.4.4 → 0.4.6

package/skills/skhema-operate/references/auth.md

@@ -0,0 +1,110 @@
+# Authenticate and bind the right org
+
+Almost every command needs a credential. This is how to get one, how the
+CLI decides which one to use, and how to read the org binding so you act on
+the right organization.
+
+## First, is the CLI even installed?
+
+```sh
+skhema --version
+```
+
+If that fails, install it:
+
+```sh
+npm install -g @skhema/cli
+```
+
+## Two credential lanes
+
+**API key — for headless, CI, and agents.** A long-lived `sk_live_…` string
+bound to one organization. No browser needed. This is the right lane for any
+non-interactive runtime.
+
+- Store one: `skhema auth key use sk_live_…`
+- Or pass per-invocation: `skhema … --api-key sk_live_…`
+- Or set the env var: `export SKHEMA_API_KEY=sk_live_…`
+- Create a new key (needs an interactive login first):
+  `skhema auth key create --name "ci-runner" --permission read-write --scope org --use`
+  (`--permission` is `read | write | read-write`; `--scope` is `org | user`;
+  `--use` stores it as the CLI credential immediately.)
+- List / revoke: `skhema auth key list`, `skhema auth key revoke <key-id>`
+
+**OAuth session — for a human at a terminal.** A browser login bound to the
+org you consent to.
+
+- `skhema auth login` (interactive browser flow)
+- `skhema auth login --headless` (device-code flow — no local browser; use
+  on a remote box or in a container)
+
+## Credential precedence (highest wins)
+
+The CLI resolves ONE credential per invocation, in this fixed order:
+
+1. `--api-key <key>` flag
+2. `SKHEMA_API_KEY` environment variable
+3. stored API key (`skhema auth key use`)
+4. OAuth session (`skhema auth login`)
+
+Consequence: a stray `SKHEMA_API_KEY` in the environment silently overrides
+your stored key and your OAuth session. If a command acts as the wrong
+identity, check the env var first.
+
+## Always know who you are
+
+```sh
+skhema auth status
+```
+
+Prints which credential is active and which org it resolves to. Run it
+whenever a result looks like it came from the wrong organization, or before
+any write you can't easily undo.
+
+## The org binding — the trap on the OAuth lane
+
+- An **API key** is bound to its org at creation. You cannot switch it; to
+  act on a different org, use a key issued for that org.
+- An **OAuth session** acts on the org you consented to. Change it:
+
+```sh
+skhema auth switch <org-slug>
+skhema auth switch                 # no slug: pick from consented orgs
+skhema auth switch --headless      # device-code consent fallback
+```
+
+If writes land in the wrong org on the OAuth lane, you skipped
+`auth switch`. There is no per-command org override for the OAuth session —
+switch it, confirm with `auth status`, then act.
+
+## Handling exit code 3
+
+Exit **3** means no usable credential resolved. Do NOT retry the same
+command — it will keep failing. Instead:
+
+1. `skhema auth status` — confirm nothing is active.
+2. Headless / CI / agent? Set an API key (lane 1). Human at a terminal?
+   `skhema auth login`.
+3. Re-run the original command.
+
+## The other credentialed exit codes
+
+- **4** (permission/plan denied, 403/402): the credential is valid but not
+  allowed to do this — wrong permission on the key (`read` key attempting a
+  write), wrong role, or a plan gate. Don't re-auth; change what you're
+  asking or which key you use.
+- **5** (rate limited, 429): back off, then retry.
+
+## Registered-agent identity (autonomous runtimes)
+
+If this runtime was enrolled as a registered agent, it signs its own
+requests instead of carrying a key:
+
+```sh
+skhema agent status --verify     # show and verify this runtime's identity
+skhema agent rotate              # rotate the signing key; identity + grants unchanged
+```
+
+Enrollment (`skhema agent enroll <token>`) is a one-time onboarding step —
+see the `skhema-setup` skill. Never cache a derived agent JWT; let the CLI
+sign per request.

package/skills/skhema-operate/references/author-elements.md

@@ -0,0 +1,158 @@
+# Author elements in the environment
+
+Elements are the unit of strategy in Skhema: one typed judgment, decision,
+or thing. This capability is about getting well-formed elements INTO a
+workspace and keeping them clean. The thinking — what the challenge is, how
+to phrase the policy — is the practice skills' job (`skhema-frame`,
+`skhema-compose`). Do that first; then land it here.
+
+## Before you write anything
+
+1. **Know the workspace.** Set it once: `skhema workspace use <id>`. Every
+   command below then omits `--workspace`.
+2. **Know the component it belongs in.** Elements live inside components,
+   and components follow the five-part flow: Diagnosis → Method &
+   Positioning → Portfolio of Initiatives → Measures → Support Structures.
+   List what exists: `skhema component list`. Create one if needed:
+   `skhema component create --type diagnosis --name "Diagnosis"`.
+3. **Know the element's type and its expected mood.** Every element type
+   carries an expected grammatical mood. If the content doesn't match the
+   mood, the type is wrong:
+   - **indicative** — a claim about the world (judgments): key_challenge,
+     supporting_fact, impact, competitor_move, constraint,
+     assumption_hypothesis, estimate, baseline.
+   - **imperative** — a command (decisions to act): guiding_policy, scope,
+     experiment, action, principle.
+   - **noun_phrase** — a thing: solution, investment, outcome,
+     performance_variable, capability, system.
+
+   Plain check: is this element stating something you believe is TRUE,
+   something you've decided to DO, or NAMING a thing? A `guiding_policy`
+   phrased as a wish ("we want to be the leader") is mistyped — a policy is
+   a command ("compete only on integration depth, never price").
+
+## Placement is enforced — and it is not the same question as mood
+
+Two different questions; don't conflate them. **Mood** (step 3) tells you how
+to *write* the element — indicative for a judgment, imperative for a command,
+a noun phrase for a thing. It is a check on the sentence. **Placement** tells
+you *where the element is allowed to live*, and the platform enforces a strict
+type→component allow-list that does NOT follow mood. Put a type in the wrong
+component and `element create` rejects it. There is no discovery command for
+this; the allow-list is:
+
+| Component | Element types it accepts |
+|---|---|
+| Diagnosis | key_challenge, supporting_fact, impact |
+| Method & Positioning | guiding_policy, competitor_move, scope, constraint |
+| Portfolio of Initiatives | solution, assumption_hypothesis, experiment, action, estimate, investment |
+| Measures | baseline, outcome, performance_variable |
+| Support Structures | capability, system, principle |
+
+Where this bites if you place by mood: `constraint` is a claim about the world
+but lives in **Method**, not Diagnosis. `assumption_hypothesis` and `estimate`
+are judgments but live in the **Portfolio of Initiatives** — so an evidence-gap
+assumption goes in the Portfolio, not Diagnosis, even though it feels
+diagnostic. Place by this table, then flag the semantic oddity in the element's
+`reasoning`.
+
+## Create one element
+
+Quick path — flags:
+
+```sh
+skhema element create \
+  --component-type diagnosis \
+  --element-type key_challenge \
+  --content "Enterprise buyers churn at renewal because onboarding never proved value."
+```
+
+Full-payload path — for anything richer than content + types, write JSON and
+pipe it. This avoids shell-quoting pain and lets you set fields the flags
+don't cover:
+
+```sh
+skhema element create --file ./element.json
+cat element.json | skhema element create --file -
+```
+
+Use `--json` on the command to get back `{ ok, command, data }`; read
+`data.id` for the new element id.
+
+## Edit an element
+
+```sh
+skhema element update <element-id> --content "Sharper restatement of the same judgment."
+skhema element update <element-id> --file ./patch.json
+```
+
+Change the type when the content's mood shifts — e.g. a `key_challenge` that
+you've now decided how to attack becomes a separate `guiding_policy`
+element, not a retyped one. One element, one judgment; don't overload.
+
+## Write good element content
+
+- **One judgment per element.** If content contains an "and" joining two
+  claims, split it into two elements and link them.
+- **Falsifiable, not vague.** "Improve customer experience" is not a
+  challenge; "first-response time exceeds 48h for 40% of tickets" is.
+- **Evidence separate from claim.** A `supporting_fact` cites; a
+  `key_challenge` asserts. Don't smuggle the evidence into the challenge.
+- **State it so a second reader reads it the same way.** Ambiguity here
+  becomes disagreement three components downstream.
+- **Meta-annotations go in `reasoning`, never in `content`.** Evidence-gap
+  notes, pre-mortem provenance ("surfaced by the competitor pre-mortem"),
+  tripwire conditions, confidence caveats — none of that belongs in `content`.
+  `content` is the clean claim a reader sees in the workspace; `reasoning` is
+  where you record why the element is there and what's shaky about it.
+
+## Link elements to show the reasoning
+
+Elements gain meaning from their relationships. A policy addresses a
+challenge; a measure tracks an outcome. Make those explicit:
+
+```sh
+# link create takes --source/--target flags; notes go in a --file payload:
+echo '{"sourceElementId":"<policy-id>","targetElementId":"<challenge-id>","notes":"policy addresses this challenge"}' > link.json
+skhema link create --file link.json
+skhema link create --file ./link.json
+```
+
+Two things about links as they stand today:
+
+- **`--type` is accepted but not persisted.** The stored link keeps only
+  `sourceElementId`, `targetElementId`, `confidenceLevel`, `notes`, and
+  `status` — no type field. Don't rely on `--type` to carry `addresses` /
+  `tracks` / `supports`; put the relationship's meaning in `notes` as plain
+  text.
+- **Element links have no read path.** There is no `skhema link list`. You can
+  create, update, and delete a link but not enumerate links later, so you
+  cannot reconstruct the reasoning graph from links after the fact. Capture
+  anything you'll need later in the element's `reasoning` or the link's `notes`
+  at write time.
+
+## After authoring: validate
+
+Don't declare an element done because it saved. Run the validation loop —
+`references/validation-loop.md` — to check completeness and coherence, read
+the diagnostics, and revise. Authoring and validating are one cycle, not two
+steps.
+
+## Attach evidence as resources
+
+A claim backed by a document is stronger than one that isn't. Attach files,
+URLs, or citations to the element:
+
+```sh
+skhema resource upload ./market-study.pdf --element <element-id> --attribution "Q2 buyer survey"
+skhema resource list --element <element-id>
+```
+
+## Verify attachment after create
+
+The create response is `{ element: {…}, componentId: "…" }` — the attachment
+proof is the **top-level `componentId`**, NOT `element.componentId` (that
+nested field is always null; checking it reports a false orphan on every
+create). A null top-level `componentId` means the element was created but
+attached to nothing — stop, note the element id, and don't retry into that
+component (known platform bug).

package/skills/skhema-operate/references/navigate.md

@@ -0,0 +1,110 @@
+# Find things in a workspace
+
+Before you change or reason about a strategy, you have to locate it. This
+capability is the reading half of the environment: which workspace, what's
+in it, where a thing lives, and what a strategy actually contains.
+
+## Start at the workspace
+
+```sh
+skhema workspace list                 # every workspace you can reach
+skhema workspace get <workspace-id>   # one workspace's detail
+skhema workspace use <workspace-id>   # set it as default; drop --workspace after
+```
+
+If you're unsure which workspace holds the thing you want, `list` first and
+read the names. Everything below assumes a default is set (or you pass
+`--workspace <id>`).
+
+## The hierarchy, top to bottom
+
+```
+workspace
+└── component        (Diagnosis, Method & Positioning, Portfolio, Measures, Support)
+    └── element      (one typed judgment / decision / thing)
+        ├── link         (element → element: addresses, supports, tracks…)
+        └── resource     (files, URLs, citations backing the element)
+strategy             (a committed snapshot of elements/components)
+```
+
+Learn the shape of a workspace by walking it:
+
+```sh
+skhema component list                  # the five-part structure in this workspace
+skhema element list                    # CAUTION: org-corpus read — see below
+skhema document list                   # workspace documents (correctly scoped)
+skhema component-link list             # component-to-component relationships
+```
+
+## Search instead of scrolling
+
+When you know roughly what you're after but not where it is, search beats
+listing. It's full-text over the workspace's elements:
+
+```sh
+skhema element search "renewal churn" --limit 10
+skhema element search "pricing" --workspace <id>
+```
+
+Use search to answer "have we already said this somewhere?" before authoring
+a duplicate, and to find the element an id-less request refers to ("update
+the onboarding challenge").
+
+## Read one thing in full
+
+```sh
+skhema element get <element-id>        # content, type, and metadata
+skhema resource list --element <id>    # what evidence is attached
+```
+
+There is no read path for element-to-element links: you can create links but
+not enumerate them, so you cannot list "what connects to this element" after
+the fact. Capture relationship context in the element's `reasoning` (or the
+link's `notes`) at write time — you can't recover it from the links later.
+Component-to-component links *do* have a read path (`skhema component-link
+list`).
+
+Reconstruct the argument, not just the parts, by reading each element's
+`reasoning` and walking the five components in order (Diagnosis → Method →
+Portfolio → Measures → Support). Because element links can't be enumerated, the
+`reasoning` field and the component structure — not a link graph — are how you
+rebuild why each element is there.
+
+## Read a whole strategy
+
+A strategy is a committed set of elements — the durable, shareable artifact.
+
+```sh
+skhema strategy list                   # strategies in the workspace
+skhema strategy get <strategy-id>      # the strategy WITH its committed elements
+```
+
+`strategy get` is the fastest way to see "what did we actually commit to?"
+as one object, versus the live, in-progress elements in the workspace.
+
+## Get results as data
+
+Add `--json` to any read command and parse the `{ ok, command, data }`
+envelope instead of scraping the human table. For agents this is the default
+posture: `data` on a `list` or `search` is an array you can iterate; `data`
+on a `get` is the object. Read ids off `data`, then act.
+
+## When a read returns nothing or the wrong org
+
+- Empty list where you expected content → wrong workspace (check
+  `skhema workspace use` / `--workspace`) or wrong org.
+- Right workspace, wrong org's data → the credential is bound to another
+  org. `skhema auth status`, then `skhema auth switch` (OAuth) or use the
+  right key. See `references/auth.md`.
+
+## Known platform gap: element reads are not workspace-scoped
+
+`element list` and `element search` currently return the ORGANIZATION's
+element corpus regardless of `--workspace` (first page = oldest elements,
+which is usually a different workspace's set). Until fixed:
+
+- Trust `component list` (correctly workspace-scoped; `elementCount` tells
+  you what's really in each component) and `element get <id>` (reliable
+  by id).
+- Track the ids of anything you create; never infer a workspace's contents
+  from `element list` output.

package/skills/skhema-operate/references/surfaces.md

@@ -0,0 +1,67 @@
+# Pick the right surface
+
+Skhema exposes the same environment through three surfaces. They are not
+ranked — each wins for a different situation. Pick before you start; the
+choice shapes how you authenticate, how you read results, and how you
+recover from errors.
+
+## The three surfaces
+
+**CLI — `skhema` in a terminal.** The default for an agent with shell
+access. One binary, the credential precedence and exit-code contract are
+built in, `--json` gives you a parseable envelope. Best for: interactive
+work, CI steps, shell-driven agents, one-off commands, anything scriptable.
+
+**Public API — `api.skhema.com/v1`.** Raw HTTP. Best for: code running
+inside an application (not a shell), a language without the CLI installed,
+or when you need a route the CLI doesn't wrap yet. It is self-describing —
+`GET /v1/openapi.json` returns the full live route surface. You still need
+a credential (an API key in the `Authorization` header, or a JWT obtained
+by key exchange).
+
+**MCP — Skhema tools inside the agent.** Best when you are already an agent
+in an MCP-capable host and want Skhema as native tools rather than shelling
+out. Registered by `skhema init` or `skhema-setup`. No terminal, no HTTP
+plumbing — the host handles auth and transport.
+
+## How to choose
+
+| Situation | Surface |
+|---|---|
+| You have a shell and the CLI is (or can be) installed | **CLI** |
+| You're inside application code, no shell | **Public API** |
+| The CLI doesn't wrap the route you need | **Public API** (`skhema api …` or raw HTTP) |
+| You're an MCP-host agent and want native tools | **MCP** |
+| CI pipeline step | **CLI** with `--api-key` or `SKHEMA_API_KEY` |
+| You need to discover what routes exist | **Public API** — `GET /v1/openapi.json` |
+
+When two fit, prefer the CLI: it centralises the credential precedence, the
+`{ ok, command, data|error }` envelope, and exit codes 0–5 so you don't
+reimplement them.
+
+## The CLI is a thin client over the same API
+
+`skhema element create` and `POST /v1/.../elements` do the same thing. So
+you can mix: script the common path with the CLI, and reach for a raw route
+only where the CLI has no wrapper. The escape hatch is built in:
+
+```sh
+skhema api routes                       # list every live gateway route
+skhema api GET /workspaces              # raw authenticated GET (leading /v1 optional)
+skhema api POST /workspaces --data @body.json
+skhema api GET /workspaces/<workspace-id>/elements --query limit=10
+```
+
+`skhema api` uses the same credential precedence as every other command, so
+you get authenticated raw access without hand-rolling headers. The gateway
+does NOT infer your organization from the path — the org comes from the
+credential (an API key's binding, or your consent-selected OAuth org). If a
+raw call returns the wrong org's data, fix the credential, not the path.
+
+## Don't fight the surface
+
+- Reading one field off one object from a shell → CLI, not raw HTTP.
+- Bulk work across hundreds of objects from app code → Public API, drive it
+  with real code, not a shell loop over the CLI.
+- Already have MCP tools bound → use them; shelling out from an MCP agent
+  just adds a credential you have to manage separately.

package/skills/skhema-operate/references/validation-loop.md

@@ -0,0 +1,84 @@
+# The validation loop
+
+An element that saved is not an element that's sound. Validation checks it
+for completeness and coherence, hands back diagnostics, and you revise until
+the judgments hold. This is a LOOP, not a final step — author, validate,
+read, revise, re-validate.
+
+## Budget first — validate is an AI action
+
+`skhema element validate` and `skhema element rephrase` run model
+inference server-side. They cost credits, unlike list/get/search which are
+cheap reads. Spend accordingly:
+
+- Don't validate after every keystroke. Author the element as well as you
+  can by hand first (right type, right mood, one judgment, falsifiable),
+  THEN validate.
+- Batch: get a component's worth of elements into decent shape, then
+  validate the ones that matter.
+- Re-validate only what you changed. If diagnostics flagged element A and
+  you edited A, re-validate A — not the whole component.
+
+## The loop
+
+**1. Validate.**
+
+```sh
+skhema element validate <element-id> --json
+```
+
+Read the `data` in the `{ ok, command, data }` envelope. It carries the
+diagnostics — completeness gaps and coherence problems.
+
+**2. Read the diagnostics as concrete defects.** Each finding maps to a
+fixable defect. Translate it before you act:
+
+- *Type/mood mismatch* — the content's mood doesn't match the element type
+  (a `guiding_policy` phrased as a wish, a `key_challenge` that's actually a
+  solution). Fix the wording OR change the type — whichever makes the mood
+  match the intent.
+- *Incompleteness* — a claim with no evidence, an outcome with no measure, a
+  policy that addresses no challenge. The fix is usually a NEW linked element
+  (a `supporting_fact`, a measure) plus a `skhema link create`, not an edit
+  to this one.
+- *Ambiguity / vagueness* — the content reads two ways, or uses a term that
+  isn't pinned down. Rewrite it so a second reader reads it once way only.
+- *Incoherence* — it contradicts or duplicates another element. Reconcile
+  the two: merge, delete one, or make the tension explicit.
+
+**3. Revise.** Edit directly, or ask the service to propose a rewrite:
+
+```sh
+skhema element update <element-id> --content "…the sharpened version…"
+# or, to get a model-proposed rephrase (also an AI action — costs budget):
+skhema element rephrase <element-id> --json
+```
+
+Treat `rephrase` output as a proposal, not a commit. Read it, decide, then
+`update` with the version you actually want. Don't chain rephrase→rephrase
+hoping it converges — that just burns budget.
+
+**4. Re-validate the changed element.** Repeat 1–3 until the diagnostics
+come back clean.
+
+## Stop conditions
+
+Stop the loop when EITHER:
+
+- Validation returns no material findings — the judgments hold. Done.
+- The remaining findings are ones you deliberately accept (e.g. an
+  assumption you know is unevidenced and have typed honestly as
+  `assumption_hypothesis`). Record why, and move on. Not every finding
+  demands a fix; some are the map telling the truth.
+
+Do NOT loop indefinitely chasing a perfect score. Two or three passes on a
+real element is normal; more than that usually means the element is trying
+to be two elements — split it and validate the halves.
+
+## Validate the whole before you commit
+
+Individual elements can each be sound while the strategy they form isn't.
+Before committing elements into a strategy (`skhema strategy commit`), walk
+the links (`references/navigate.md`) and check the cross-element story:
+every challenge has a policy, every outcome has a measure, nothing
+contradicts. Coherence is a property of the set, not the parts.

package/skills/skhema-pressure-test/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: skhema-pressure-test
+description: "Use when a strategy or a decision needs to survive contact with reality — attack it the way a competitor, a skeptical board, or an indifferent market will, before they do. This is the adversary's chair, not a self-check."
+---
+
+# Pressure-Test
+
+You play the adversary against the user's own strategy. Not to be cruel — to
+find the weak joints before reality does, while there's still time to fix them.
+
+This is the grill-me of strategy. You are the competitor who moves against
+them, the board member who won't fund hand-waving, the market that simply
+doesn't care. You attack. They defend. What survives is stronger; what breaks
+gets fixed today instead of in eighteen months.
+
+## What this is (and what it is not)
+
+Pressure-testing is deliberately hostile. That is the point. A strategy the
+author checks for tidiness (that is `skhema-calibrate` — the self-check) can
+still be perfectly consistent and completely doomed. Pressure-testing asks a
+different question: **not "is this coherent?" but "will this hold when someone
+wants it to fail?"**
+
+You are not the user's teammate right now. You are the thing standing between
+them and success. Stay in character.
+
+## The one rule that keeps it fair
+
+Relentless, but fair. **Every attack must name its defeater** — the specific
+evidence or decision that would kill the attack. "This won't work" is noise.
+"This assumes buyers switch for a 10% price gap; if they'd switch for 5% you're
+fine — do you know which it is?" is an attack, because it tells them exactly
+what would end the argument.
+
+An attack you cannot defeat with any conceivable evidence isn't an attack. Drop
+it. You are testing the strategy, not venting.
+
+## The three adversaries
+
+Pick the one that bites hardest for each attack.
+
+- **The competitor** — moves against them the day after they commit. Asks:
+  what do I do to make this fail? Where's the opening?
+- **The board skeptic** — controls the money and has seen a hundred decks.
+  Asks: where's the evidence? What happens if you're wrong? Why this and not
+  the obvious alternative?
+- **The market that doesn't care** — not opposition, indifference. Asks: why
+  would anyone change what they do today for this? What if they just... don't?
+
+## Ground rules for the ritual
+
+- One attack at a time. Let them answer before the next.
+- Attack the load-bearing claim, not the typo. Go where it hurts.
+- Steelman before you knife: attack the *strongest* version of their argument,
+  not a weak one you invented.
+- The output is decisions, not a scorecard. End by asking what they'll change.
+- Drop the adversary coat the instant they need help fixing something. You wear
+  it to find the wounds, not to gloat over them.
+
+## Capabilities
+
+| Capability | Route here when… | Reference |
+|---|---|---|
+| Full grill | They have a whole strategy and want it stress-tested end to end. | `references/full-grill.md` |
+| Decision grill | One decision or bet is on the table and they want it attacked hard. | `references/decision-grill.md` |
+| Pre-mortem | They want to surface failure modes they can't yet see — imagine it already failed. | `references/pre-mortem.md` |
+
+## Routing logic
+
+- Whole strategy in front of you → **full-grill**. Work the component flow,
+  attack the weakest links first, keep a ledger.
+- A single choice, bet, or decision → **decision-grill**. Go deep on that one
+  thing: the case against it, the competitor's counter, when it's wrong.
+- "What could go wrong that we're not seeing?" → **pre-mortem**. Assume it
+  failed, narrate why backwards, then make the strategy carry each cause
+  visibly as an assumption or a risk.
+
+These chain. A pre-mortem surfaces failure causes → a full-grill works breadth
+across the whole strategy → a decision-grill goes deep on the one bet that
+survived shakiest. Offer the next move when one ends.
+
+## When an attack lands and there's no answer
+
+Most unanswerable attacks point at a missing judgment. Either a claim they've
+been treating as true without ever testing it (a belief they assumed was a
+fact), or a decision they never actually made (they've been acting as if the
+choice was settled when it wasn't). Name which one. That's the fix: write the
+judgment down, honestly typed, so the strategy carries it in the open instead
+of leaning on it in the dark.
+
+## 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
+
+This ritual works with pen and paper. If the user keeps their strategy in
+Skhema, every attack that lands can be written straight back as a typed element
+— an assumption with its evidence gap, a risk with its tripwire — so the
+pressure-test leaves a durable trail instead of a memory. `@skhema/method`
+(`npm i @skhema/method`) gives you the typed vocabulary (assumption, risk,
+constraint, decision) and validates that each new judgment is well-formed. The
+skill needs none of this to do its job.