@skhema/cli 0.4.4 → 0.4.5

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.

package/skills/skhema-pressure-test/references/decision-grill.md

@@ -0,0 +1,127 @@
+# Decision Grill — interrogate one decision hard
+
+One choice is on the table. Go deep, not wide. Build the strongest case against
+it, force it to survive the smartest competitor's response, and name the exact
+conditions under which it's wrong. Then help them decide: keep it, kill it,
+hedge it, or set a tripwire.
+
+## Before you start
+
+Get the decision stated as a decision — a command, something they will *do*:
+"We will move upmarket and drop the free tier." If what you hear is mushy
+("we're thinking about the enterprise space"), sharpen it first. You can't
+attack a fog. Make them commit to a sentence, then attack the sentence.
+
+Sometimes the sharpest thing on the table isn't a decision at all — it's a
+*judgment*, a claim like "consented-data supply, not analytics, is the binding
+constraint." You can't grill a claim as a decision, but you can promote it:
+state the command that claim justifies ("so: we will invest in consented-data
+supply, not more analytics"), confirm that's the real bet, then grill *that*.
+Promoting a judgment to its implied decision is a distinct move from sharpening
+a fog — the fog has no content yet; the judgment has content but no verb.
+
+## The moves
+
+### 1. Steelman it first
+
+Say the best case *for* the decision, out loud, in your own words. This is not
+politeness — it's how they know your coming attack is fair. It also flushes out
+their real reasons: if your steelman is stronger than theirs, they may not have
+thought it through.
+
+"The case for this is: your free tier attracts users who never convert and cost
+you support, while the enterprise buyers you actually want are put off by a
+consumer-grade free plan. Dropping it sharpens the product and the buyer. That's
+a real argument. Now here's the problem with it."
+
+### 2. The strongest case against — just one
+
+Not three weak objections. The one that hurts. Find the single argument that,
+if true, makes this decision a mistake — and make it as hard as you can. Name
+its defeater.
+
+"The strongest case against: your free tier is your top of funnel. Half your
+enterprise deals started as a free user who became a champion inside their
+company. Kill the free tier and you kill the pipeline that feeds the very
+buyers you're chasing. If you can show that enterprise deals *don't* originate
+from free users — pull the numbers — this dies. Can you?"
+
+### 3. The competitor's response
+
+A decision isn't made in a vacuum. The smartest competitor reacts the day after
+you commit. Ask: what do they do, and does your decision get *better or worse*
+once they've moved?
+
+"You drop your free tier. Your sharpest competitor keeps theirs and runs ads
+saying 'still free, still here.' Every price-sensitive user you shed walks
+straight to them, and some of those would have grown into your buyers. Does your
+decision assume competitors hold still? They won't."
+
+The strongest decisions get *better* under competitive response (the competitor
+can't follow without hurting themselves). The weak ones assume no one reacts.
+
+### 4. The conditions under which it's wrong
+
+Name the world-states where this decision is a mistake. Be specific — these
+become the strategy's tripwires.
+
+"This is wrong if: (a) more than a third of enterprise deals trace back to free
+users, or (b) your paid conversion from the new top-of-funnel is slower than
+the free-to-champion path you're removing. Two conditions. Here's the real
+question:" —
+
+### 5. Would you know you're in that world?
+
+For each condition, ask how they'd *know*. A condition you can't detect is a
+landmine. If they can't name the signal, that's a finding: the decision needs
+an instrument before it's safe to make.
+
+"How would you know deals stopped originating from free users — what would you
+watch, and how long before the damage is done? If you can't see it for two
+quarters, you're flying blind on your biggest risk."
+
+### 6. The reversibility question
+
+One-way door or two-way? Cheap to unwind or not? This changes everything about
+how much certainty they need before committing. A reversible decision can be
+made on a hunch and corrected; an irreversible one demands the evidence you've
+just been demanding.
+
+"If dropping the free tier turns out wrong, can you bring it back? Or have you
+lost the users, the SEO, the muscle memory? If it's a one-way door, you need to
+be far more sure than you are right now."
+
+## End on a verdict — theirs
+
+Hand them four options and make them pick:
+
+- **Keep** — it survived; the case against didn't land or was defeated by
+  evidence.
+- **Kill** — the case against held; the decision is a mistake.
+- **Hedge** — make it smaller or reversible so being wrong is survivable (run
+  the free tier in one segment, not kill it everywhere).
+- **Tripwire** — make the decision, but install the instrument from move 5 so
+  you'll *know* if you've entered a world where it's wrong, and pre-commit to
+  what you'll do then.
+
+## What good looks like
+
+- The decision was stated as a crisp command before any attack.
+- You steelmanned it before knifing it.
+- One strong case against, not a scatter of weak ones.
+- The competitor's reaction was played out, not assumed away.
+- The "wrong-if" conditions came paired with "how would you know."
+- Reversibility was named explicitly.
+- It ended with keep / kill / hedge / tripwire — their call, not yours.
+
+## Common failure modes
+
+- **Attacking a fog.** Grilling a decision that was never stated as one. Sharpen
+  to a command first.
+- **A pile of weak objections.** Three soft doubts feel thorough but let the real
+  risk hide. Find the one that hurts.
+- **Assuming a static world.** Forgetting the competitor moves. Always play the
+  response.
+- **Conditions with no detector.** Naming when it's wrong but not how you'd know
+  — that's a landmine, not a safeguard.
+- **Deciding for them.** You built the case; they make the call.

package/skills/skhema-pressure-test/references/full-grill.md

@@ -0,0 +1,118 @@
+# Full Grill — interrogate a complete strategy end to end
+
+Attack the whole strategy the way reality will. Work it in flow order, hit the
+weakest links first, keep a running ledger of what survived and what broke, and
+end with the user deciding what to change. This is not a review that produces a
+document. It's an interrogation that produces decisions.
+
+## Before you start
+
+Get the strategy in front of you. If it's already written, read it. If it's in
+their head, pull it out fast — you'll test it as they say it.
+
+A strategy has five parts, in this order. Use them as your map:
+
+1. **Diagnosis** — what's actually going on / the core challenge.
+2. **Method & Positioning** — the approach they've chosen to win, and where
+   they sit versus everyone else.
+3. **Portfolio of Initiatives** — the concrete things they're doing about it.
+4. **Measures** — how they'll know it's working.
+5. **Support Structures** — the capabilities, systems, and resources that make
+   it possible.
+
+Ask them to state the strategy in these five slots. **If they can't fill a
+slot, that's your first finding** — write it in the ledger and keep going.
+A strategy missing its diagnosis or its measures is already broken; you don't
+need to attack it, just point at the hole.
+
+## The moves
+
+### 1. Map fast, then rank by fragility
+
+Once you have the five slots, don't attack top-to-bottom. Scan for the weakest
+link — the claim most load-bearing and least defended — and go there first.
+Weak links are usually: a diagnosis stated as fact with no evidence, a
+positioning claim that any competitor could also make, a measure that wouldn't
+actually move if the strategy failed.
+
+Tell them where you're starting and why: "Your whole plan rests on X being
+true. So I'm starting there."
+
+### 2. Attack one link, name the defeater, hear the answer
+
+Pick the adversary that bites hardest (competitor / board skeptic / indifferent
+market). Land **one** attack. Name the defeater in the same breath — what
+evidence or decision would end your attack. Then stop and let them defend.
+
+Bad: "Your positioning is weak."
+Good (competitor): "You're positioning on speed. I'm your biggest competitor and
+I'm already faster. What's left for you? If you can point to a segment that
+values something I *can't* copy, this attack dies — can you?"
+
+Record the verdict before moving on:
+- **Survived** — they answered with evidence or a real decision.
+- **Broke** — no answer; the link doesn't hold.
+- **Needs evidence** — plausible, but resting on a belief they haven't tested.
+
+### 3. Attack the joints, not just the parts
+
+The dangerous failures live between the components. A strategy can have five
+strong parts that don't connect. Test the joints:
+
+- Does the **Diagnosis** actually justify the **Method**? Or did they pick a
+  method they liked and back-fill the diagnosis?
+- Do the **Initiatives** attack the diagnosis, or just keep people busy?
+- Would the **Measures** actually *drop* if the Method were failing? If a
+  measure stays green while the strategy dies, it's decoration.
+- Do the **Support Structures** exist yet, or is the plan assuming capabilities
+  they'd have to build first?
+
+Joint attacks are the ones authors never see coming, because each part looks
+fine alone.
+
+### 4. Keep the ledger visible
+
+Maintain a running ledger the user can see as you go. It's the spine of the
+ritual — it turns a barrage into a map.
+
+```
+LEDGER
+[Diagnosis]      Survived      — churn data backs the "retention not acquisition" call
+[Positioning]    Broke         — "faster" is copyable; no defensible segment named
+[Initiative 3]   Needs evidence— assumes sales team can sell upmarket; untested
+[Measure: NPS]   Broke         — wouldn't move if the real problem (onboarding) got worse
+[Joint: Diag→Method] Survived  — method directly attacks the named challenge
+```
+
+### 5. End on decisions, not a verdict
+
+When you've worked the weak links, read the ledger back and hand the floor over:
+"Here's what held and what didn't. What are you going to change?" Let them
+drive. Your job was to find the wounds; theirs is to decide which to treat.
+
+If a broke or needs-evidence line points at a missing judgment — a belief
+they've been treating as fact, or a decision they never actually made — say so.
+That's the concrete fix: write it down, typed honestly, so the strategy carries
+it in the open.
+
+## What good looks like
+
+- Every attack named its defeater; none were unanswerable venting.
+- You started at the load-bearing weak link, not the top of the page.
+- At least one joint between components got tested.
+- The ledger is legible on its own — someone who missed the session could read
+  it and know where the strategy is soft.
+- It ended with the user naming changes, not with you delivering a grade.
+
+## Common failure modes
+
+- **Breadth over depth.** Landing forty shallow jabs instead of six that hurt.
+  Rank by fragility; spend your attacks on load-bearing claims.
+- **Attacking the wording.** Sniping at phrasing is `skhema-calibrate`'s job,
+  not yours. You attack whether it *holds*, not whether it *reads well*.
+- **Unfair strawmen.** Attacking a weak version they didn't mean. Steelman
+  first — state the strongest reading, then attack that.
+- **Never dropping the coat.** Staying hostile once they're trying to fix
+  something. The moment they turn to repair, help them.
+- **Ending with a report.** A scorecard they file and forget. End with the
+  question: what will you change?

package/skills/skhema-pressure-test/references/pre-mortem.md

@@ -0,0 +1,140 @@
+# Pre-Mortem — assume it already failed, then make the strategy carry the causes
+
+Most people ask "what could go wrong?" and get polite, vague answers. The
+pre-mortem cheats that instinct: you don't ask *if* it fails, you declare that
+it *has*, and work backwards from the wreckage. Then — the part people skip —
+you convert every failure cause into something the strategy visibly carries: a
+named assumption or a named risk with a tripwire. A failure cause you can name
+but don't write down is a failure cause you'll walk straight into.
+
+## The moves
+
+### 1. Set the scene — it failed, no hedging
+
+Put them eighteen months in the future. The strategy is a clear, acknowledged
+failure. Not "might struggle" — it *failed*, and everyone knows it. Make them
+sit in it before they start explaining it away.
+
+"It's eighteen months from now. This strategy failed. Not partially — it's the
+thing people point to as the mistake. You're in the room where that's obvious to
+everyone. Don't tell me it might not happen. It happened. Now tell me the story
+of how."
+
+The certainty is the trick. "What could go wrong" invites optimism and
+defensiveness. "It failed, why?" gives people permission to say the thing they
+were quietly worried about.
+
+### 2. Narrate backwards to a decision made today
+
+Get the top failure story, then walk the causal chain back. Keep asking "and
+what caused *that*?" until you land on a decision or assumption that exists
+*today*. The whole value is connecting the future wreck to a present choice they
+can still change.
+
+"So it failed because enterprise buyers never showed up. And why not? Because
+sales couldn't sell upmarket. And why couldn't they? Because you assumed — today
+— that your current team could learn enterprise selling, and you never tested
+it. There. That's a decision you're making right now."
+
+### 3. Run it from each adversary
+
+Don't stop at one obituary. The same strategy fails different ways depending on
+who kills it. Walk the pre-mortem from each:
+
+- **The competitor killed it** — what did they do that you didn't survive?
+- **The market killed it by indifference** — nobody changed their behaviour;
+  the thing you built, nobody wanted enough to switch.
+- **You killed it yourselves** — you couldn't execute; the capability, focus, or
+  resources weren't there.
+
+Each lens surfaces a different class of cause. The internal-execution one is the
+most commonly skipped and the most often fatal.
+
+### 4. Harvest every distinct cause
+
+List them. One line each, plainly. Don't smooth them into a narrative — you want
+the discrete causes, because each one becomes a thing the strategy has to carry.
+
+```
+FAILURE CAUSES
+1. Assumed current sales team could sell upmarket; never tested.
+2. Competitor cut price and we had no answer.
+3. Onboarding was too hard; users never reached the value moment.
+4. We under-resourced the migration and it slipped two quarters.
+```
+
+### 5. Convert each cause into a carried judgment
+
+This is the move that makes the pre-mortem worth doing. For every cause, turn it
+into one of two things the strategy now holds *in the open*:
+
+- **A typed assumption** — a thing you're *betting is true*. State it as a claim
+  about the world, then attach the evidence that would confirm or kill it, and
+  whether you actually have that evidence. ("We assume our sales team can learn
+  enterprise selling. Evidence: none yet. Status: untested bet.")
+- **A named risk with a tripwire** — a thing that could go wrong, plus the
+  signal you'll watch and the action you'll take if it fires. ("Risk:
+  competitor price cut. Tripwire: their published price drops below ours;
+  action: we compete on X, not price.")
+
+Which type? If the cause is *a belief you're relying on*, it's an assumption. If
+it's *an event that could hit you*, it's a risk. The distinction between "a
+thing we've decided is true" and "a thing we've decided to do about a danger" is
+the whole discipline — an assumption you never test and a risk you never watch
+are the same landmine wearing two hats.
+
+**Encoding this in Skhema.** There is no `risk` element type in the taxonomy, so
+both halves land as `assumption_hypothesis`. A belief is the bet stated as a
+claim. A risk is *also* an `assumption_hypothesis` — the bet that the danger
+stays away — paired with a linked `experiment` or `action` that carries the
+tripwire: the signal you'll watch and what you'll do when it fires. The tripwire
+condition itself goes in the element's `reasoning` field until the taxonomy
+grows a better home for it. Don't reach for a `risk` type; it doesn't exist.
+
+```
+CAUSE 1 → ASSUMPTION: Sales team can sell upmarket.
+           Evidence held: none. Status: untested. Action: run 3 enterprise
+           deals before committing the plan to this.
+CAUSE 2 → RISK: Competitor price cut.
+           Tripwire: their price < ours. Response: compete on integration
+           depth, do not match on price.
+CAUSE 3 → ASSUMPTION: Users can self-onboard to the value moment.
+           Evidence held: current activation rate 22% — weak. Status: shaky.
+CAUSE 4 → RISK: Migration under-resourced.
+           Tripwire: any milestone slips > 2 weeks. Response: pull in help now,
+           don't wait for the second slip.
+```
+
+### 6. Hand back what the strategy now carries
+
+The output is the list from move 5: the assumptions the strategy is betting on
+and the risks it's watching, each one traceable to a way this could actually
+fail. Give it to them and let them decide which to act on now, which to
+instrument, and which they're willing to bet on with eyes open.
+
+The strategy hasn't changed yet — but it's stopped pretending. Every quiet
+worry is now written down, typed, and owned.
+
+## What good looks like
+
+- The framing was "it failed," not "it might fail" — no hedging allowed.
+- At least one cause traced back to a decision or assumption live *today*.
+- All three adversaries got a turn; the internal-execution failure wasn't
+  skipped.
+- Every harvested cause was converted — none left as a loose worry.
+- Each assumption names its evidence (or admits it has none); each risk names a
+  tripwire and a response.
+
+## Common failure modes
+
+- **Letting them hedge.** "It probably would've been fine, but…" — cut it. It
+  failed. Why?
+- **Stopping at symptoms.** "Revenue was low" is not a cause. Chase it back to a
+  decision made today.
+- **Only the external villains.** Competitor and market are easy to blame;
+  "we couldn't execute" is the one that's usually true and usually skipped.
+- **Harvesting without converting.** A list of scary stories you file away is a
+  wasted pre-mortem. The point is the assumptions and risks the strategy carries
+  out the other side.
+- **Assumptions with no evidence line.** If you don't record what would confirm
+  or kill the bet, you've made a wish, not an assumption.

package/skills/skhema-challenge-framing/SKILL.md

@@ -1,28 +0,0 @@
----
-name: skhema-challenge-framing
-description: "Guide strategic challenge articulation—avoid symptoms, ensure actionable and bounded problem statements."
----
-
-# Challenge Framing
-
-Guide users through articulating strategic challenges with precision.
-
-## When to Use
-
-- Starting a new strategy process
-- When a problem feels vague or overwhelming
-- When stakeholders disagree on "the real issue"
-
-## Key Principles
-
-- Challenges are not symptoms
-- A well-framed challenge is specific, bounded, and actionable
-- The framing itself is a strategic choice
-
-## Process
-
-TODO: Define the step-by-step process
-
-## Examples --> what does good look like?
-
-TODO: Add worked examples

package/skills/skhema-coherence-check/SKILL.md

@@ -1,28 +0,0 @@
----
-name: skhema-coherence-check
-description: "Examine strategic elements for internal consistency—flag contradictions, tensions, or gaps between decisions."
----
-
-# Coherence Check
-
-Validate that a set of strategic elements form a coherent whole.
-
-## When to Use
-
-- After multiple elements have been defined
-- When strategy feels fragmented
-- Before communicating strategy to others
-
-## Key Principles
-
-- Coherence is not automatic—it must be checked
-- Tensions may be acceptable if acknowledged
-- Gaps are often invisible until explicitly sought
-
-## Check Types
-
-TODO: Categories of coherence issues
-
-## Process
-
-TODO: How to systematically check for coherence

package/skills/skhema-element-decomposition/SKILL.md

@@ -1,28 +0,0 @@
----
-name: skhema-element-decomposition
-description: "Break strategic questions into discrete judgment elements—surface individual decisions and their dependencies."
----
-
-# Element Decomposition
-
-Help users decompose strategy into its constituent judgment elements.
-
-## When to Use
-
-- After a challenge has been framed
-- When facing a complex strategic question
-- To create clarity on what decisions actually need to be made
-
-## Key Principles
-
-- Each element represents a single judgment or decision
-- Elements have dependencies and sequences
-- Decomposition reveals hidden complexity
-
-## Process
-
-TODO: Define the decomposition method
-
-## Element Types
-
-TODO: Categorize types of strategic elements