Nmt Craft Value Proposition

Craft Value Proposition v2

New here, or not sure this is the right skill? Start right here — or run nmt-chat, describe your situation, and it points you to the right one. Quick map: new idea → nmt-market-research · live product or a metric moved → nmt-diagnose · have customer interviews → nmt-analyze-interviews · ready to build → nmt-product-requirements · positioning / launch copy → nmt-craft-value-proposition → nmt-craft-go-to-market.

This skill takes a customer group you want to win — described by you in plain words, or handed over from a nmt-market-research run — and works out the strongest, testable reason they'd switch to you (the value proposition), plus a build-ready spec the next skill can turn into a PRD.

It sits in the middle of the chain:

nmt-market-research → nmt-craft-value-proposition → nmt-product-requirements → nmt-craft-go-to-market
(segment + tasks +   (the value hypothesis +     (the build: PRD —        (landing + ad +
 why-we-win +         implementation spec for     functionality +          GTM/growth comms)
 competitors)         the PRD hand-off)            edge cases)

nmt-market-research hands over a customer group with the tasks they're trying to get done, what "good enough" means to them (success criteria), the bigger result they're after, their competitors, and a one-line take on why you'd win. This skill goes much deeper: it pins down the few things this customer weighs above everything else (their dominant success criteria), maps the run of tasks the customer walks (the Job Graph the value moves operate over), generates ways to create value by walking a catalog of named value moves (value mechanics) over that map, then filters and ranks them on feasibility, cost-to-build, the money math (unit economics), and whether they actually beat competitors. The output's implementation spec is what nmt-product-requirements builds the PRD from.

The bigger gift is invention — systematically generating the strongest / fastest / cheapest way to create value — not validation. Validation (the test cards — the Riskiest Assumption Test, RAT) is the deliverable, not the differentiator.

The output is a single file. The default the reader sees is short — a one-page value proposition: what it is, who it's for, why they'd switch, the one bet that has to be true, and what to do next. Two deeper layers sit below it, collapsed and opt-in, so the document also serves the skeptical read, the methodology audit, and the PRD hand-off — but nobody hits a wall of detail they didn't ask for:

1. Layer 1 — The value proposition (the default view, ~1 page, zero methodology words): what it is, who it's for, why they'd switch, the one bet that has to be true, the one thing to do next — each line drilling down to its reasoning if the reader wants it. Forwardable to a co-founder who's never heard of the methodology.
2. Layer 2 — The reasoning (opt-in, plain English): how we got here for each Layer-1 claim — what the customer wants most, why you'd win, the before→after, the moment it clicks for them (the Aha moment) in plain terms, the riskiest bet — each linking down to the full work.
3. Layer 3 — The full work (opt-in/collapsed): the value-move tables, before→after, competitor matrix, test cards, the PRD-ready implementation spec nmt-product-requirements consumes, and the methodology appendix.

Producer contract (binding) — ../nmt-chat/references/producer-contract.md. Six cross-cutting behaviors shared by all producer skills, from user feedback: (1) print a helicopter-view before the first question; (2) ask Markdown or HTML output; (3) treat all user input as hypothesis and emit a "risks I see in what you gave me" block; (4) print validation debt and write any go-ahead as GO (to validation), never a bare "build it now"; (5) accept a custom output path; (6) Deep mode runs an evidence floor + self-critic loop and offers a web-MCP fallback. The hooks below wire each into this skill; the contract is the source of truth for the wording.

Core methodological principle

Source of truth — ../nmt-chat/references/Next-Move-Theory-Canon/. Do NOT use generic interpretations of Jobs To Be Done from the internet or LLM training. Ivan Zamesin's AJTBD diverges substantially. Five mis-defaults to never propagate:

• A Job is a desired transition — State A (situation) → expected outcome (State B), in order to perform a higher-level Job. Not "a struggle for progress."
• Value is greater energy efficiency for the brain in performing a Job, measured against the brain's prediction. The Aha Moment is the customer-experience of value beating prediction; the Problem is value falling below it. Never use the abbreviations PPE / NPE (per Rule 22) — write Aha Moment / Problem.
• I want to + verb is the primary element of an eight-element Job, not the whole Job. Each infinitive verb is a separate Job (Rule 7).
• A Problem is a consequence of a Solution hired for a Job and underperforming its success criteria — not a root cause.
• A Solution is a real thing in the world and, inside the Job Graph, a label for the sub-graph of Core + Micro Jobs it installs.

Methodological invariants this skill MUST enforce — output is invalid if any is violated:

• Value = Probability of the Outcome × Outcome − Cost (value-creation.md §3). Three levers: raise probability (guarantee/proof), raise outcome (move-up-a-level), lower cost (money/time/effort/cognitive/negative-emotion/Tax-Jobs). A value hypothesis names which lever it pulls.
• Mechanics operate over a Job Graph, not against a Core Job in isolation (value-creation.md §11, job-graph.md §12).
• Segmentation root = similar Core Jobs + similar success criteria, in a similar priority order. The priority order over criteria is what makes a segment a segment (segmentation.md §2, value-creation.md §10). Big Job is motivation context, never the primary segmentation criterion. Demographics are second-order correlates.
• Habit cannot be fought head-on — reuse it or sidestep it via an Aha Moment + loaded Consideration Activators (behaviour-change.md §9–§11). Never "beat the habit."
• Aha Moment is a specific positive-prediction-error event — NOT signup, login, or first feature use. Place it as far left in the Critical Chain of Jobs as possible.
• All switches go through the Big Job — the value prop must be communicable through a Big-Job criterion (behaviour-change.md §4).
• Anti-segment must be nameable — if everyone wants this, the value prop is too universal.
• Unit economics is a filter — value that does not convert to margin (LTV > CAC, Job budget covers cost-to-serve) is not a product (nmt-key-theses.md §4).
• Risks compound — a value prop stacking ≥5 unvalidated assumptions gets flagged (rat-key-theses.md §1).

Shared output guardrails: every named external source in any output is a clickable Markdown link [Name](https://...). Put the numerical + hallucination disclaimers at the top of result.md. Outputs are written for a US product audience — default to US-context analogs.

Plain-language output — segment words first, methodology in parentheses

The reader of this output is a product person, not a methodologist. Write the user-facing document in the plain, everyday language the target segments already use; when a methodology term genuinely adds precision, lead with the plain meaning and put the term in parentheses the first time it appears — never lead a sentence, bullet, or heading with a methodology label.

• ❌ "Red Queen value-gap compression…" · "the Critical Chain of Jobs breaks at M4" · "load the Consideration Activators."
• ✅ "The free do-it-yourself option caught up, so your edge shrank even though you didn't get worse (in the methodology, a Red Queen effect)."

Who reads it — the target segments (the essentials are inline here, so the skill stays self-contained and public-safe): US founders, indie hackers / vibe-coders, growth-stage PMs, senior PMs / VPs, and product marketers. Their vocabulary: PMF, runway, pivot, a niche that pays, ship it, first paying customers, a roadmap I can defend, a metric that moves (not theater), positioning, conversion. Avoid the words they reject: scale fast, 10x, hockey stick, proven framework, growth / funnel hacks, 5 hacks — and methodology jargon as the lead.

Plain ↔ methodology (lead with the plain meaning; add the term in parentheses once, when it earns its place — common-word terms like segment, success criteria, Aha moment you can lead with directly): the bigger result they're really after (their Big Job) · the biggest task your product does on its own, end to end, and can't go higher right now (its Core Job) · the ordered run of must-succeed tasks the customer walks (the Critical Chain of Jobs) · the exact step where they get stuck (a break in that chain) · the Aha moment, where the product beats what they expected and it clicks · getting the result for less time, effort, money, or stress than expected (value) · the few things you load into a buyer's head before they'll switch (Consideration Activators) · a real blocker that stops them using you vs. just a worry (a Barrier vs. a fear) · the assumption most likely to kill this, tested cheap first (the riskiest assumption — the Riskiest Assumption Test, RAT). Never say Positive / Negative Prediction Error to a user — write Aha moment / Problem. Don't say wedge — say "why we win" / "the underserved criteria only you cover."

Precision still holds in the methodology layer. Job-grammar discipline (Jobs as "I want to + verb," levels named, terms capitalized) governs the internal-reasoning held in context and the explicit §12 Methodology appendix (NMT) inside Layer 3, where full methodology language is expected. The lead the reader sees in Layers 1–2 (and in Layer-3 prose) is plain; the parenthetical and the appendix carry the precise terms.

Link references/glossary.md once at the top of Layer 2, where the methodology terms first appear.

Readability rules (the document is for a customer who doesn't know the methodology)

The value-proposition document is three reading depths in one file, linked top-to-bottom like canon §-references. Most readers stop at Layer 1; doubters drop one level to see how we got here; experts read the bottom (the full mechanic work + the PRD-ready spec). The full template is in "S6 — Synthesize the artifact (three layers)" below. The rules that make it work:

• Three layers, escalating depth — state each conclusion once per layer, never twice at the same depth. Layer 1 = the value proposition (the one-page default, headline only). Layer 2 = the reasoning in plain English. Layer 3 = the full methodology work (the mechanic tables, before→after, competitor matrix, RAT cards, the §11 implementation spec, the §12 appendix). A bet is a headline in L1, a plain sentence in L2, a full RAT card in L3 — three depths, not three copies.
• Drill-down links are mandatory. Every Layer-1 claim a skeptic could doubt carries a ▸ link to its Layer-2 anchor; every Layer-2 claim links to the Layer-3 part that derives it. Use Markdown anchors: write [how we know they'll switch ▸](#l2-bet) and put <a id="l2-bet"></a> above the target. This is what makes the simple layers trustworthy — the reader can always click through to the derivation.
• Layer 1 = minimal jargon, plain words lead. Lead every sentence in plain product English a junior PM gets at a glance. A methodology term may appear in parentheses as a short plain gloss when it genuinely helps — but never open a sentence with a raw term, and keep jargon to a minimum. Short sentences — "explain it to a smart friend." Watch the sneaky business-jargon leaks: wedge, bet, beachhead, ACV read as jargon too — translate them (wedge → "the one thing only we do"; the bet → "the one thing that must be proven first") or gloss in parentheses.
• Layer 2 = plain language first, term glossed. On first use, gloss a methodology term in 3–5 words in parentheses — e.g., "the Big Job (the outcome the customer is really after)". Nested or repeated parenthetical glosses are fine — clarity beats purity. Link references/glossary.md once at the top of Layer 2.
• No internal methodology citations in Layers 1–2. Never write "per behaviour-change.md §1", "per Rule 7", or any canon file path in the readable layers.
• Layer 3 may carry methodology citations — but fenced, not inline. This is the biggest readability fix for this skill: the old output embedded inline citations everywhere ([Value Creation §10](…), (per [Behaviour Change §1]), internal rule numbers). No canon path or Rule N appears inline in Layer-3 prose. Put each canon reference in a collapsed methodology trace at the end of a subsection, styled out of the reading flow, e.g.:

  ▸ methodology trace. Value = Probability × Outcome − Cost (value-creation.md §3); mechanics operate over the Job Graph (value-creation.md §11); segmentation root = similar Core Jobs + similar success criteria in a priority order (segmentation.md §2). Never break a sentence of report prose with (value-creation.md §11). The §12 methodology appendix MAY keep a single consolidated canon-references list — it is an explicit appendix — but the body prose stays clean. Project-internal rule numbers never appear in any layer, including §12 — they are for your reasoning, not the reader.

• Disclaimers once. The two-part disclaimer appears once (top of file), plus a one-line pointer in Layer 1. Do not repeat the full disclaimer block inside Layer 3. (Search the file before shipping — the disclaimer wording should hit at most twice.)
• Keep source links for external facts (Rule 2).

Enforcement gate (these kept getting skipped in real runs — check each before writing the file; full version in ../nmt-chat/references/readability-contract.md):

• Unique, resolving anchors. Every ▸ drill-down link points to its own unique <a id="…"> that exists exactly once; no two links share a target. The live failure for this skill was two different Layer-1 links both pointing at #l2-bet, and l3-value+l3-segment stacked on one heading — give each its own anchor. Before shipping, list every ▸ target and confirm each resolves to one place.
• Inline-gloss opaque Layer-3 table headers. A non-obvious column header carries a 3–6-word plain gloss right there. Don't rely on the glossary file — a casual reader never opens it.

Methodology — source of truth (progressive loading)

The only source of methodology is the Next Move Theory canon, read at runtime (relative paths; the skill ships in the same repo as the canon). Don't load all of it up front — read the eager core first, then pull the staged files only when the run reaches the stage that needs them (the same progressive-disclosure pattern Skills use with references/). This keeps a Quick run light and lets each Deep-mode agent read only its slice.

This is a public skill — it grounds only in the public canon. Every file in the sets below is a published canon file (the set whitelisted in 8-Tools/sync/PUBLIC_MANIFEST.yml); the skill ships to the public mirror, where private files do not exist. Never read or quote any canon file outside the sets below — the value-creation algorithm, the unit-economics theory, and the full mechanics catalog are folded into the public files below; their deeper private and paywalled forms are out of bounds. This holds in both repos — even when running inside the Internal repo where those files exist on disk.

Eager core (read before any analysis — every run):

Staged — load only at the stage that uses it:

Quick mode (one primary agent): read the eager core, then read each staged file the first time the run reaches its stage — not before. Deep mode: each agent reads only the files its wave needs (the [S1] dominant-criteria agent → eager core + segmentation.md + job-structure.md; [S2] job-graph → critical-chain.md (+ job-graph.md if needed); [G*] mechanic generators → eager core + behaviour-change.md; [F] feasibility → nmt-key-theses.md; [RAT] → rat-key-theses.md; [SYN] → communication.md). Never have an agent load a file outside its slice.

Path note: if a file is not found, retry with a 1- prefix on the canon folder (1-Next-Move-Theory-Canon/...) — the source repo orders folders with a numeric prefix the public repo strips.

The pipeline (S0 → S6 with critic gates)

S0  Intake & Route ───(human: input path, mode, target segment)
     │
S1  Dominant success criteria + anchors ──────────► GATE-1 ─┐
     │                                                        │ loop ≤2 rounds,
S2  Job-Graph substrate (Micro + Critical Chain of Jobs) ─► GATE-2 ─┤ then escalate to human
     │
S3  Value-hypothesis GENERATION (divergence) ─────► GATE-3 ─┤  ⇇ Deep: parallel mechanic-family
     │   "strongest / fastest / cheapest way"                │      agents + reviews-mining
S4  Feasibility · Cost · Competitiveness FILTER ──► GATE-4 ─┤  ⇇ Deep: web-grounded competitor matrix
     │   + unit-econ + RICE → top 1–2
S5  De-risk (RAT cards) ──────────────────────────► GATE-5 ─┘
     │
   ──(human: pick PRIMARY vs SUPPLEMENTARY)──
     │
S6  Synthesize artifact (US value-prop + appendix + impl spec) ► GATE-6 (panel) ──(human: ship)

This is the value-creation algorithm (value-creation.md §11–§14, inside the the-algorithm.md strategic spine) with nmt-key-theses.md §4 as the unit-economics filter and rat-key-theses.md as the de-risking layer. The spine is a prompt-chaining workflow with an evaluator-optimizer gate after each substantive stage — not an autonomous agent.

The critic / gate design (shared by every GATE)

Each GATE is an adversarial, binary, evidence-citing critic grounded in the canon — in Quick mode a self-critique pass, in Deep mode a separate critic agent. The verdict rule:

You are an adversarial reviewer. REFUTE the output; find the strongest reason each
criterion FAILS before deciding it passes. Default to REJECT under uncertainty — a
criterion passes ONLY with a cited span of evidence. Do NOT rewrite; only judge + instruct.

Per criterion → { verdict: pass | fail, evidence: "<exact span>", critique: "<specific, actionable>" }
Overall      → { overall: pass | fail, blocking: [...], fix_instructions: "<ordered changes>" }
Binary verdicts only — no 1–5 scores.

• Hard checks are deterministic, not LLM-judged — run them as code-style checks (Job grammar = one I want to + infinitive; every external number carries a clickable link; a hypothesis is stated as mechanic × Core Job × criterion × alternative, never as a bare feature).
• Loop control: generate → judge → pass ships; fail feeds fix_instructions back to the generator. Max 2 rounds, then escalate to the user (prevents the self-correction-degradation failure mode). If a round's critique repeats the prior round's unresolved issues, escalate immediately.
• GATE verdicts stay in-context, not in the user-facing file.

Output file (one file per run)

The skill writes exactly one file. Default location (used unless the user gave a custom output path in intake — producer-contract.md §5), grouped under the product's folder in the project root (never TMP/ or a Client configuration directory):

Skills-Results/{product-slug}/craft-value-proposition/{YYYY-MM-DD_HH-MM}_{product-slug}-craft-value-proposition-result.{md|html}

• Extension follows the chosen output format (producer-contract.md §2): .md (default) or a single self-contained .html (inline CSS, working in-page anchors for the How-to-read jumps + every ▸ drill-down link, source links opening in a new tab). Either format leads with the one-page value proposition (Layer 1) and keeps Layer 2 + Layer 3 collapsed in <details> blocks — collapsed <details> renders on the GitHub Markdown mirror too, so the default view is short in both. HTML also uses <details> for methodology traces. HTML carries the identical content — same attribution, disclaimers, three layers, tables, links — just in a more readable shell. Never write both; one file per run.
• If the user gave a custom path, write the one file there with the same filename pattern.
• Everything else — the normalized input, the ranked criteria, the Job Graph, the raw hypotheses, the scored shortlist, the RAT inventory, dropped hypotheses, and every GATE verdict — stays in-context across the stages; none of it is written to a separate file. The timestamp makes each run's file unique, so reruns never overwrite. Disclaimers (Rule 3) go at the top of this one file.

Attribution (Rule 23). The file opens with the attribution top-line (the very first content, above the disclaimers) and closes with the attribution block — utm_source=nmt-craft-value-proposition&utm_medium=skill-artifact.

Quick mode (default, ~10–15 min, no internet)

One primary agent, no internet, no subagents. Runs the full S0→S6 chain inline; each GATE is a self-critique pass with the adversarial prompt above, grounded in the canon. Feasibility and competitiveness are reasoning-grade (Deep mode grounds them on the web).

Canon loading (Quick). Read the eager core (value-creation.md + value-creation-mechanics.md) at run start; pull each staged file the first time the run reaches the stage that uses it — not before (see "Methodology — source of truth"). Build the Layer-3 work first (S0→S6), then compute Layer 2, then Layer 1, LAST from the finished Layer-3 work, wiring the ▸ drill-down links to the Layer-3 anchors. Write the single file in the order: top disclaimers once → Layer 1 → Layer 2 → Layer 3.

S0 — Intake & Route

Orientation (helicopter view) — print before any question

First, the orientation block (producer-contract.md §1) — print it before any question, in plain words:

What you'll get: one document — your value proposition (what it is, who it's for, why they'd switch), the top-3 things to test before building, and a PRD-ready spec the next skill (nmt-product-requirements) can build from. The steps: (1) a few questions about your segment + input → (2) I pull out what this customer wants most → (3) I generate many ways to create value and filter them on feasibility, cost, unit economics, and how well they beat competitors → (4) I rank them and surface a primary + a back-up value prop with test cards → (5) you get one document in three reading depths. Where I work vs. where you decide: I do the analysis, the invention, and the hypotheses. You pick the primary value prop and run the field validation — interviews, fake-door tests, first sales. I can't validate for you; I can only tell you what to check first and how. Two modes: Quick (default — no internet, ~10–15 min, reasoning only; good for a first cut and "did I miss a stronger angle") · Deep (opt-in — subagents + web research, longer; real competitor and review data; best on a top model with a web-research MCP). Honest caveat: this speeds up the thinking, not the proving. Every value prop here is a hypothesis until you check it in the field.

Then proceed to intake.

Intake depth — ask this first

The very first thing in the intake, before anything else. This is about the number of questions I ask you — it's independent of the Quick / Deep research mode (that's about internet + subagents, asked later). Ask via a structured-input request:

First — how deep should I go? Pick one:

• Just the essentials — I ask the 3–4 questions that matter most, then deliver. Best for a fast first pass or when you're still exploring.
• The full interview — I walk you through everything so we cover the most blind spots and you get the highest-confidence result. Best when the decision is expensive.

Hold the choice in context. Just the essentials → ask only the load-bearing questions (input path · segment + the 1–3 main things they're getting done + business goal); infer or defer the rest (materials, claims ledger, hand-off debt), and note in result.md what was skipped. The full interview → run the complete intake below (materials, claims ledger, hand-off debt, direction confirmation). Either way the engine still builds the full eight-element Job structure internally.

Language

Default English. If the user writes in another language, offer to work in it via a structured-input request (English / their language / Other). Hold the choice in context. The report uses the chosen language; canon files and source URLs stay as-is.

Determine input path

Lead with the standalone path — it is a first-class door, not a fallback. Open with: "Tell me your customer group and what they're trying to get done — or point me at a nmt-market-research result if you have one. Both work." Then ask via a structured-input request:

Q1: "How do you want to start?"
- "I'll describe my segment myself"         → path C: standalone manual intake (first-class)
- "I have a nmt-market-research result file"   → path A: load and parse
- "I want to run nmt-market-research first"    → path B: hand off, then come back

Path A — nmt-market-research result loaded. Ask for the result file path, read it with the active Client's file-reading capability, and parse the segment list. Then:

Q2: "Which target segment(s)?" (list the ✅/⚠️ segments parsed from the result)
- Pick 1 (recommended) or 2 (max). Push back on 3+.

Q3: "What's the active business goal?"
- "Launch a new product"
- "Reposition an existing product"
- "Expand an existing product into a new segment"
- "Other — I'll describe"

Hand-off debt — what's been validated since (producer-contract.md §4c). The nmt-market-research result carried a validation debt (its risky assumptions, the RAT in its Section 5). Ask once: "That research left a list of unvalidated assumptions. Which of them have you since checked in the field — interviews, sales, a test — and what did you learn?" Carry the answers in context: anything confirmed becomes evidence (cite how it was checked); anything still unchecked stays tagged unvalidated and flows into S5's RAT cards. Debt travels down the chain — it is not silently dropped.

Path B — wants nmt-market-research first. Reply: "Good call if your market's still fuzzy — a nmt-market-research run sharpens the value prop. Run nmt-market-research (Quick or Deep), then come back here with the result file. Want me to open the nmt-market-research input prompt now?" Hand off. (Don't push this on anyone who'd rather just describe their segment — path C is a fully supported door.)

Path C — describe your segment yourself (a first-class door, not a fallback). Collect the input in plain words — never ask the user to write a Job in any formal structure. You collect plain answers and build the eight-element Job structure internally in the engine; the user only ever speaks normal English. Ask via plain-text prompts:

Required (plain words — no formal structure asked of the user):
- Product description (1–2 sentences) + URL if any
- Who's this for? Describe them by what they do and how they're set up,
  not their age/title — and what sets them off to look for a fix.
- In a sentence or two each: what are the 1–3 main things this customer is
  trying to get done, and how would they know it worked?
  Plain words — I'll structure it into the formal version (their Core Jobs).
- The bigger result they're really after by doing those things (their reason / Big Job).
  For B2B, also the personal win for the individual making the call.
- Known alternatives — ≥3 ways this customer gets that result today (with URLs)
- Active business goal (launch / reposition / expand)

From these plain answers, build the eight-element Job structure internally (context · negative emotions · Consideration Set · trigger · expected outcome · success criteria · positive emotions · higher-level Job) and validate that internal structure against the invariants — without showing the formal grammar to the user. If something's missing or off, ask for it in plain words (e.g. "is there a specific moment or event that sets this customer off to look for a fix?"; "you named two different things they're getting done there — let's take them one at a time") — never "that Job has two infinitive verbs" or "that criterion is demographic." Translate the methodology check into a plain question. Flag reduced confidence at the top of result.md: "⚠️ Confidence reduced — value prop generated from a manual segment description, not a full nmt-market-research run."

Run options & output (all paths)

Ask in one batched structured-input request (defaults keep the common case friction-free):

• Mode — Quick (default; fast; no internet) / Deep (subagents + web competitor mining).
• Output format (producer-contract.md §2) — Markdown (default; faster) / HTML (a bit slower; easier to read — collapsible sections + working in-page navigation; all source and drill-down links stay clickable).
• Where to save the result (producer-contract.md §5) — default Skills-Results/{project}/craft-value-proposition/… / or a folder path to match your repo (e.g., docs/research/). Skip = default. One file per run regardless of location (Rule 4).

User materials, claims ledger, direction confirmation (all paths)

• Materials. Ask once: "Any files or folders with material I should use — a Notion export (markdown), past research, interview notes, a strategy doc, your current site, a deck, a codebase?" Read what's given; tag everything taken from it [user data] in-context. "Nothing" is a fine answer.
• Input-as-hypothesis gate (producer-contract.md §3). Treat all input — the nmt-market-research result, the user's free-text claims, every uploaded deck / landing / codebase / past research — as hypothesis, never established fact. A landing page is the team's belief about value, not proof customers want it; the Job stated in a deck may be the team's projection, not the customer's real Job (the most expensive error). Don't just record the input — actively hunt the risks inside it: for each load-bearing input ask — is this customer-validated or the team's belief? Does the stated Job / segment look like the real one? Any internal contradictions, or guesses dressed as data? What must be true for it to hold, and is that checked? Hold the findings in context — they become the "What you told me — and the risks I see in it" block in Layer 2, with the single worst one surfaced in Layer 1. Never silently bake an unvalidated input into the wedge or the value prop.
• User-claims ledger. Collect the strong factual claims the user made (segment beliefs, competitor facts, "customers always…"), tag each as data / observation / hunch (ask in one batched question if unclear; hunch is the default for anything from a deck / landing / idea stream). User claims enter the pipeline as hypotheses, never facts: GATE-4's competitiveness check treats an unverified user claim as unsupported evidence, and a primary value prop resting mainly on a user hunch gets flagged in result.md with a RAT card pointed at that claim.
• Hard gate. No value prop or wedge may rest primarily on an unvalidated user input without the document saying so explicitly and pointing a RAT card at it. If the wedge is built on a Job taken from the user's materials and not confirmed by customer evidence, name that as the single most expensive risk.
• Direction confirmation. Before S1 starts, play the understanding back in one short block — "Here's what I understood: {segment, Core Jobs, business goal, what's out of scope}" — and confirm via one structured-input request (Confirm / Correct). Cheapest moment to fix a wrong direction.

Output (held in context): target segment + causal criteria · Core Jobs (canonical form, "in order to" not "so that") · Big Jobs (+ personal Big Job for B2B) · known alternatives/competitors (direct · indirect · turnkey) · the nmt-market-research why-we-win line & first mechanic guess (path A) · user materials + claims ledger · mode · language · business goal.

S1 — Dominant success criteria + anchors → GATE-1

Objective. Extract all success criteria from the target segment's Core Jobs, classify each on the six cost dimensions and the eight criteria-priority orders (value-creation.md §8–§10), and rank to the 1–3 dominant criteria that define this segment. Pull the §11 lead-mechanic shortlist for those criteria.

Procedure:

1. List every success criterion across the chosen Core Jobs. Each must have a direction (which axis: price / latency / comfort / privacy …) and a level (the threshold above which the customer feels value — job-structure.md §8). Rewrite adjectives into concrete criteria ("fast" → "car arrives in under 4 minutes").
2. Tag each criterion by cost dimension (money / time / effort / cognitive load / negative emotion / Tax Jobs) and name the segment's priority order (speed-first / price-first / done-for-me-first / no-stress-first / reliability-first / control-first / status-first / privacy-first — or a 2–3 criterion combination).
3. Rank to the dominant set — the 1–3 criteria whose priority defines the segment. State why these dominate (from the persona's causal criteria), not just that they do.
4. Map to lead mechanics using value-creation.md §11 (e.g. done-for-me-first → Take the Job off the customer; no-stress-first → Remove negative emotions). This shortlist seeds — does not cap — S3.
5. Anchors: capture the Big-Job ladder (each dominant criterion must ladder up to a Big-Job criterion), the alternatives list, and the segment's triggers.

Output (held in context): ranked dominant criteria (direction + level) · priority-order label · per-criterion cost dimension · lead-mechanic shortlist · Big-Job ladder · alternatives.

GATE-1 acceptance criteria (yes/no, evidence-cited):

• ▢ Criteria are concrete (direction + level), not adjectives.
• ▢ The dominant set (1–3) is identified with a causal rationale, not merely listed.
• ▢ Each dominant criterion ladders up to a named Big-Job criterion.
• ▢ Lead mechanics are drawn from the §11 map for this priority order.
• Hard checks: every Core Job is a single I want to + infinitive; every external number carries a clickable link.

S2 — Job-Graph substrate (Micro + Critical Chain of Jobs) → GATE-2

Objective. Build the surface the mechanics operate over: the Job Graph one level below the top 1–2 Core Jobs (the Micro Jobs the person performs in order to perform the Core Job), and the Critical Chain of Jobs (the graph projected onto a time axis) with break-points marked. Mechanics apply to a graph, not a Job in isolation.

For each of the top 1–2 Core Jobs (highest importance × frequency), generate the lower-level graph using this prompt:

Work according to Advanced Jobs To Be Done methodology.

Describe the Job Graph one level below the Core Job for segment
{SEGMENT_NAME + CAUSAL_CRITERIA} for product {PRODUCT_DESCRIPTION + URL}.

Core Job: {CORE_JOB in canonical When / I want to / in order to form with success criteria}

For every Job one level below the Core Job, output:
- when: { context · trigger · loaded Consideration Activators · negative emotions at State A }
- I want to {expected outcome: verb + noun}
  - success criteria: { concrete, direction + level }
- in order to {how this lower Job serves the Core Job above it}
- Problem(s) [if any] + strength on a 1–10 scale

Output 5–10 lower-level Jobs as a sequence (or parallel branches if the Core Job
has parallel sub-flows). Then project them onto the Critical Chain of Jobs and mark:
breaks · cycles · role hand-offs · time-gaps · Tax Jobs.

Output (held in context): 5–10 Micro Jobs per Core Job + the Critical Chain of Jobs with break-points flagged. This is the substrate S3 operates on.

GATE-2 acceptance criteria:

• ▢ Nodes are real Jobs (verb form), anchored to past performance — not future-tense fantasy (no Fake Jobs).
• ▢ The Critical Chain of Jobs marks at least the break / cycle / hand-off points.
• ▢ Levels are named and product-relative (Rule 20).
• ▢ "For what? / in order to do what?" resolves at every node (job-graph.md §18).

S3 — Value-hypothesis GENERATION (divergence) → GATE-3

This is the core of the skill. Walk the full value-creation mechanics catalog in value-creation-mechanics.md over `(dominant criteria × Job Graph ×

…(truncated)