@skhema/cli 0.4.3 → 0.4.5

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

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

@@ -1,20 +0,0 @@
----
-name: skhema-element-writer
-description: Use when creating or editing Skhema elements, structuring element content, organizing elements into components, or applying strategy frameworks during element authoring.
----
-
-# Skhema Element Writer
-
-A skill for creating and managing Skhema elements — the building blocks of your product strategy.
-
-## Capabilities
-
-- Create new elements with proper structure
-- Edit existing element content
-- Organize elements into components
-- Apply strategy frameworks to element creation
-
-## Usage
-
-This skill is automatically available when installed to your agent platform.
-Ask your AI assistant to create or edit Skhema elements.

package/skills/skhema-judgment-audit/SKILL.md

@@ -1,28 +0,0 @@
----
-name: skhema-judgment-audit
-description: "Surface assumptions, evidence quality, and confidence levels for strategic elements. Distinguish facts from beliefs."
----
-
-# Judgment Audit
-
-Examine the foundations of strategic judgments and decisions.
-
-## When to Use
-
-- Validating critical strategic elements
-- When confidence in a decision is unclear
-- Before committing significant resources
-
-## Key Principles
-
-- Every judgment rests on assumptions
-- Evidence varies in quality and relevance
-- Distinguishing facts from beliefs prevents overconfidence
-
-## Audit Dimensions
-
-TODO: Define what to examine in each judgment
-
-## Confidence Framework
-
-TODO: How to assess and communicate confidence levels

package/skills/skhema-semantic-sharpening/SKILL.md

@@ -1,28 +0,0 @@
----
-name: skhema-semantic-sharpening
-description: "Review strategy language for ambiguity and vague terms. Ensure precise meaning and shared understanding."
----
-
-# Semantic Sharpening
-
-Review and refine strategic language for clarity and precision.
-
-## When to Use
-
-- Reviewing strategy documents or statements
-- When team members interpret terms differently
-- Before finalizing strategic commitments
-
-## Key Principles
-
-- Ambiguity is the enemy of execution
-- Many strategy failures are semantic failures
-- Precision enables accountability
-
-## Common Patterns
-
-TODO: Document common semantic traps
-
-## Techniques  --> what does good look like?
-
-TODO: Methods for sharpening language

package/skills/skhema-strategy-advisor/SKILL.md

@@ -1,20 +0,0 @@
----
-name: skhema-strategy-advisor
-description: Use when developing or refining product strategy in Skhema, including positioning, market fit analysis, competitive evaluation, and strategic recommendations.
----
-
-# Skhema Strategy Advisor
-
-A skill that helps you develop and refine product strategies using the Skhema framework.
-
-## Capabilities
-
-- Analyze product positioning and market fit
-- Generate strategic recommendations
-- Evaluate competitive landscapes
-- Create actionable strategy documents
-
-## Usage
-
-This skill is automatically available when installed to your agent platform.
-Ask your AI assistant about product strategy, positioning, or competitive analysis.

package/skills/skhema-workspace-navigator/SKILL.md

@@ -1,20 +0,0 @@
----
-name: skhema-workspace-navigator
-description: Use when navigating a Skhema workspace, inspecting workspace structure, searching workspace content, understanding hierarchy, or moving between related elements.
----
-
-# Skhema Workspace Navigator
-
-A skill for navigating and understanding your Skhema workspace structure.
-
-## Capabilities
-
-- Browse workspace components and elements
-- Search across workspace content
-- Understand workspace hierarchy
-- Navigate between related elements
-
-## Usage
-
-This skill is automatically available when installed to your agent platform.
-Ask your AI assistant to help you navigate your Skhema workspace.