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) — ../PRODUCER-CONTRACT.md. Eleven 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. Five more came from the anti-hallucination pass: (7) ask the market + audience language and build every example, channel, and price anchor from it; (8) list the repo-context files found on disk and read them only after a yes; (9) every claim carries its status — backed, derived, or the model's own hypothesis; (10) frequency counts on every aggregated claim, and a single source never carries a segment-level conclusion; (11) confidence scaled to the input — thin input gets ranges, a visible warning, and the top-3 inputs that would fix it. The hooks below wire each into this skill; the contract is the source of truth for the wording.

Core methodological principle

Source of truth — Next-Move-Theory-Canon/ in the project root. 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 (per project CLAUDE.md):

• 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).
• Every claim carries its status — backed by a quote or data, derived from the inputs, or the model's own hypothesis. An idea nobody in the inputs raised may never be written as customer demand (see "Claim statuses" below).
• A segment is Core Jobs + success criteria + the priority order over them — never a purchase channel, never an industry, never a demographic on its own (segmentation.md §2, §7; the guard checklist is in S1).

Per project CLAUDE.md: every named external source in any output is a clickable Markdown link [Name](https://...) (Rule 2). Disclaimers (numerical + hallucination) at the top of result.md (Rule 3). The market is the user's, not a default. With no market named, write for a US product audience with US-context analogs (Rule 6) — but the moment the user names a market at intake (the market question in S0 is mandatory), every example, competitor, price anchor, channel, unit, and regulation comes from that market, in the language its audience speaks. Kazakhstan is not Russia; the UAE is not the US.

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.

Claim statuses, honest confidence, and where invented ideas go

Every claim in the document carries one of three statuses — and says which one it is.

• Backed — a quote, a number, or a document stands behind it. Cite it right there; for review or interview evidence, say how many said it and link them ("7 of 22 reviews on G2 + Reddit: [links]").
• Derived — you worked it out from the inputs. Say from what: "derived from the two success criteria in your research file plus the pricing page below."
• My hypothesis — your own guess. Say so in plain words: "this is my guess; nothing you gave me says it."

Three hard rules on top:

• A number a person said is that person's opinion, not a market fact. "60–70% of deals go through tenders" ships as "per the sales lead — his estimate, not a measured figure." Same for "our customers always…" from a founder or a deck. Never promote a spoken number into a market number.
• Inventing value moves is this skill's job — dressing an invention as customer demand is not. S3 exists to generate ways to create value that no customer ever named; that is the point. What you may never do is write such a move as if the customer asked for it. A hypothesis nothing in the inputs hints at gets Confidence = low in the RICE table, ships with a plain "nobody asked for this — here's the cheapest way to find out" line, and any that doesn't make the top 2 goes into the "Ideas nobody asked for — hypotheses to validate" list in Layer 3. Two real failures this skill produced: an invented product-lifetime warranty entered a value proposition as customer-stated demand, and a refill/consumable option for a single-use device ranked #2 — an invention that contradicts the product's actual shape is dropped at S4, not ranked.
• Confidence scales to what the user actually gave you (dynamic honesty). No interviews, no analytics, no reviews — just a description — means the run is thin, and the document says so at the top of Layer 1: "⚠️ Thin input: this ran on your description alone. The numbers are ranges, the segment is a hypothesis, not a finding." On thin input use ranges ("roughly $40–120 a month"), never point numbers that imply measurement, and close Layer 2 with the top 3 inputs that would raise accuracy most (e.g. "8 interviews with landlords who self-manage," "your last 50 support tickets," "G2 reviews of {competitor}"). This is computed per run — the fixed disclaimers at the top do not cover it.

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]), [CLAUDE.md Rule 7]). 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 (CLAUDE.md Rule 7) 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 ../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.
• Zero-knowledge readability, and tooltips in HTML. Every line of the document has to make sense to someone who has never heard of this methodology — explain it the way you'd explain it to a smart 8-year-old, in everyday words. No abbreviation ships unexplained, including ones you coin yourself. In an HTML run, wrap every abbreviation and methodology term on first use in <abbr title="plain explanation"> — RICE, RAT, MVP, CAC, LTV, Core Job, Big Job, Aha moment, Consideration Activators, Critical Chain of Jobs — and write the tooltip itself in the same everyday words, never in more jargon.

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 Claude 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 Claude): 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 (per CLAUDE.md Rule 4 — 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 .claude/):

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 and <abbr title="plain explanation"> tooltips on the first use of every abbreviation and methodology term. 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 Claude, 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 AskUserQuestion:

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 (market + audience language — never skipped at any depth · 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 AskUserQuestion (English / their language / Other). Hold the choice in context. The report uses the chosen language; canon files and source URLs stay as-is.

Market & audience — mandatory, asked every run

Ask once, in the same breath as the language question: "Which market or region are you selling into, and what language do the people you're selling to speak?" Never infer it from the product's name, the user's language, or the fact that most examples you know are American.

Everything downstream comes from the market they name — the competitors you compare against, the price anchors, the willingness-to-pay read, the alternatives the customer really uses today, the regulations, the units and currency, and the examples in the write-up. Kazakhstan is not Russia; the UAE is not the US; Brazil is not Portugal. If they name a market you know only thinly, say so plainly and list what you'd want checked locally (real local competitors, local price levels, local channels). Only with no market named do you fall back to a US audience with US-context analogs.

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 AskUserQuestion:

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, 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 AskUserQuestion (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.
• Files already sitting in the working folder — list them and ask before opening any. Glance at the working directory for things that look like product context: a README or product docs, survey exports, review dumps, analytics CSVs, interview notes, existing landing copy, a pricing page. If any exist, name them and ask permission before reading a single one: "I see these files that might help: {list}. May I read them? This context is processed only by your agent locally — it is not sent anywhere." Read only the ones the user says yes to. Never open files on your own initiative.
• 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, "cust

…(truncated)