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

.

/nmt-market-research

/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

/nmt-product-requirements

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.

../nmt-chat/references/Next-Move-Theory-Canon/

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.

• 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

  ).

CLAUDE.md

[Name](https://...)

result.md

• ❌ "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)."

references/glossary.md

• 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.:

  <sub>▸ 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

  ).</sub> 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).

../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.

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.

PRODUCER-CONTRACT.md §5

TMP/

.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. 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.

utm_source=nmt-craft-value-proposition&utm_medium=skill-artifact

PRODUCER-CONTRACT.md §1

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.

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.

result.md

AskUserQuestion

• 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).

• 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

  AskUserQuestion

  (Confirm / Correct). Cheapest moment to fix a wrong direction.

value-creation.md §8–§10

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.

• ▢ 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.

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.

• ▢ 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

  ).

value-creation-mechanics.md

(dominant criteria × Job Graph × competitor weaknesses)

• Generate the way value is created, concretely — not an abstract mechanic. An app, a feature, a done-for-you service, an offline space, a flying/field service, a guarantee, a bundle, a marketplace, a concierge, a piece of content. Name the delivery format.
• Lead with the two dominant mechanics — move up a level and kill a Job (

  value-creation.md §14

  ) — and hold the invisible-product North Star (§20): what would it look like for the customer to reach the outcome with no product to interact with at all?
• Push for "fastest / cheapest" — for each strong hypothesis, name the cheapest delivery that still produces the Aha Moment (concierge, no-code, partial-value slice).
• Generate broadly — target 12–20 raw hypotheses; drop non-applicable mechanics (note them in-context).

For {target segment} performing {Core Job + dominant criterion},
we close it more efficiently by {mechanic(s)} applied to {specific graph node},
delivered as {concrete product / service shape},
which displaces {alternative} because {its specific weakness}.
Lever: {raise probability / raise outcome / lower cost — which}.
Aha Moment: {the specific positive-prediction-error event}.

• ▢ Each hypothesis is stated as

  mechanic × Core Job × criterion × alternative

  — not "we ship feature X".
• ▢ A positive-prediction-error / Aha Moment is articulable (not signup/login).
• ▢ It operates at Core-Job level or above (not Micro-polish — unless Micro-polish is the wedge for this segment).
• ▢ Habit is reused or sidestepped, never fought head-on.
• ▢ It is communicable through a Big-Job criterion.
• Hard check: no hypothesis is a bare feature; each names a mechanic and a specific displaced alternative.

1. Build feasibility & cost-to-implement. What does it actually take to build? Name the cheapest viable path (concierge / no-code / vibe-coding / partner) and the cheapest probe that proves value before the build. Flag any hypothesis whose realizability is genuinely uncertain (fusion-class impossible vs merely hard).
2. Unit-economics fit (

   nmt-key-theses.md §4

   as the filter). Does the value convert to margin? Compare cost-to-serve against the segment's Job budget and willingness-to-pay; sanity-check the LTV > CAC direction. A delightful hypothesis the segment can't profitably be served on is dropped (or flagged as a different-segment move).
3. Competitiveness — does it actually beat the competitive set on the dominant criteria? Build / extend the criteria × competitor matrix across direct (Core-Job), indirect (Big-Job), and turnkey (Big-Job-level) competitors. The wedge is an underserved criteria intersection, not a single criterion. In Quick mode this is reasoning-grade; in Deep mode it is web-grounded on real reviews.

• R (Reach) — % of the target segment for whom it applies.
• I (Impact) — subjective value to one customer.
• C (Confidence) — grounded in the nmt-market-research / canon evidence.
• E (Effort) — cost to build a probe / MVP (lower = better).
• +1 strategic bonus if the mechanic is move up a level or kill a Job (

  value-creation.md §14

  — the strongest mechanics).
• +1 defensibility bonus if it exits direct competition (Previous/Next Job, graph-shift, exclusive value).

• ▢ Competitiveness is grounded in actual competitor evidence (Quick: named competitors + their "covers poorly" criteria; Deep: cited reviews) — not bare assertion.
• ▢ Cost-to-implement estimated and the cheapest probe named for the top 2.
• ▢ Unit-econ direction is sane (Job budget covers cost-to-serve; LTV > CAC direction stated).
• ▢ Ranking math is shown; the winner beats alternatives on a dominant criterion, not a peripheral one.
• ▢ The supplementary is genuinely distinct from the primary.

• Level 1 — The value proposition (1 page, plain words): what it is, who it's for, why they'd switch, the one thing to prove first, what to do next. Most readers stop here. jump ▸
• Level 2 — The Reasoning (plain English): how we got there — what the segment wants most, the edge, the before→after, the riskiest assumption. jump ▸
• Level 3 — The Full Work (the audit trail + build spec): the full mechanic work, before→after, competitor matrix, test cards, and the PRD-ready implementation spec. jump ▸

undefined

⚠️ These are hypotheses, not facts — full disclaimer ▸

Validation debt: this value prop stands on {N} unvalidated assumptions — {M} of them fatal (would sink it if wrong). The fatal ones are the first things to test, before you build. see them ▸ <sub>N = risky assumptions across the RAT inventory; M = those that kill it if wrong. A Quick run on thin input has high debt — say so honestly (

PRODUCER-CONTRACT.md §4

).</sub>

⚠️ Confidence note: {path C → reduced-confidence flag; path A → name the source nmt-market-research file path}

<sub>▸ methodology trace. Segmentation root = similar Core Jobs + similar success criteria in a priority order (

segmentation.md §2

); the priority order is what makes a segment; demographics are second-order.</sub>

<sub>▸ methodology trace. Dominant criteria + their cost dimensions and priority order (

value-creation.md §8–§11

).</sub>

<sub>▸ methodology trace. Mechanics operate over the Job Graph, not a Core Job in isolation (

value-creation.md §11

); strongest mechanics = move up a level / kill a Job (

value-creation.md §14

); Aha = a positive-prediction-error event placed as far left on the Critical Chain of Jobs as possible (

value-creation.md §12

,

critical-chain.md

); all switches go through the Big Job (

behaviour-change.md §4

).</sub>

Above = the proposition. Below = the bet and the build.

<sub>▸ methodology trace. Risks walked across the chain (Market / Segment+Jobs / Value / Unit-economics / Channels) + product-specific custom risks; ranked by (P(wrong) × cost-if-wrong) ÷ cost-to-validate (

rat-key-theses.md

); risks compound (

rat-key-theses.md §1

).</sub>

/nmt-product-requirements

• Product shape: {what the product IS — name + components + delivery format (app / service / offline / hybrid)}.
• Feature table (delivery vehicles for value):

  Core Job / criterion	Mechanic	What we ship	Aha-Moment link
  {…}	{#mechanic}	{feature / service}	{step where value beats prediction}

• Critical Chain of Jobs & Aha placement: {the chain the customer walks; where the Aha fires; what to remove to shift it left}.
• Cost-to-build & cheapest probe: {build path + the probe that validates before building}.
• Unit-economics direction: {Job budget vs cost-to-serve; pricing hypothesis; LTV>CAC direction}.
• Who this is NOT for — out of scope: {2–3 groups this is deliberately not for; non-focal Jobs deferred}.

<sub>▸ methodology trace. Unit economics is a filter — value that doesn't convert to margin is not a product (

nmt-key-theses.md §4

; budget covers cost-to-serve,

nmt-key-theses.md §5

).</sub>

• Mechanics applied (combination) — the full table: Job × mechanic(s) × how the product performs it (typically 5–12 applications across the graph).
• The dominant-criteria → mechanics mapping used.
• Forces of behaviour change for the primary: Added Value {lever} · Problems surfaced {how} · Fears {reduction lever} · Habit {reuse / sidestep — NOT fought}.
• Canon references (consolidated):

  value-creation.md

  (§3 formula, §11 map, §14 dominant mechanics),

  value-creation-mechanics.md

  ,

  the-algorithm.md

  ,

  behaviour-change.md

  ,

  critical-chain.md

  ,

  rat-key-theses.md

  ,

  nmt-key-theses.md §4

  .

• Three layers present and correctly leveled — Layer 1 (minimal jargon, plain words lead, terms only in parentheses), Layer 2 (plain reasoning, one gloss per term, no big tables), Layer 3 (the full §0–§12 work). No conclusion repeated at the same depth across layers.
• Drill-down links resolve and are unique — every Layer-1 claim links to a real Layer-2 anchor; every Layer-2 claim links to a real Layer-3 anchor; every

  #l...

  /

  #disclaimers

  target exists exactly once and no two links share a target (the bet and the next-action are different links).
• Opaque Layer-3 table headers carry an inline plain gloss.
• Disclaimers once — full two-part disclaimer at top only; Layer 1 has the one-line pointer; this block does not repeat it.
• Citations fenced — no canon path or

  Rule N

  inline in Layers 1–2 or in Layer-3 prose; any canon reference sits in a

  ▸ methodology trace

  line; the §12 consolidated list is the only place a flat reference list is allowed; no

  CLAUDE.md Rule N

  anywhere.
• One-liner = [what it is] + [Core Jobs] + [value by criteria]
• Dominant success criteria identified and the value prop beats competitors on them
• Primary names a product + a mechanic combination + a Core Job + a displaced alternative (not a slogan)
• Supplementary is distinct from the primary
• Aha Moment is a specific in-product event (not signup / login)
• Anti-segment names 2–3 groups
• Habit reused or sidestepped (not fought head-on)
• Feasibility + cost-to-build + unit-econ direction stated
• Value hypothesis is falsifiable with a confirm/kill threshold
• ≤3 unvalidated assumptions stacked in the chosen prop
• §11 implementation spec is PRD-ready
• Every external source is a clickable link
• Producer contract satisfied (

  ../nmt-chat/references/producer-contract.md

  ): helicopter-view printed before intake; output-format + output-path asked; if HTML, one self-contained

  .html

  with resolving anchors +

  <details>

  ; the "What you told me — and the risks I see in it" block present (unless no input given); validation-debt line in Layer 1; the next step framed as validate first, not build (no bare "build it now"); on hand-off from nmt-market-research, asked what debt has been retired; Deep mode hit its evidence floor + self-critic loop (or flagged thin coverage + offered the web MCP).

1. /nmt-product-requirements

   — feed it the implementation spec (the PRD hand-off section) directly; it becomes the PRD's segment + value + risk input.

2. /nmt-craft-go-to-market

   — once the PRD exists, feed this value prop + the PRD to write the landing, ad, and GTM/growth copy.
3. Run RAT card #1 — don't build until #1 is validated or killed.

Agent

subagent_type: "general-purpose"

run_in_background: true

You work with Ivan Zamesin's AJTBD / Next Move Theory methodology. Use ONLY the canon files this prompt names for your wave as the methodology source — do NOT use generic JTBD from the internet or prior training, and do NOT read files outside your slice (the eager core is

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/value-creation.md

+

…/value-creation-mechanics.md

; other files are named per-agent below). (If a path is not found, retry with a

1-

prefix on the canon folder.) Write Aha Moment / Problem, never PPE / NPE. Keep methodology citations and canon paths out of report prose — hold them in context; the orchestrator fences any that belong in Layer 3 into a

▸ methodology trace

line. Every named external source is a clickable Markdown link. Return your full result in your final message — do not write any files.

PRODUCER-CONTRACT.md §6

• Evidence floor, not just a ceiling. The web-touching legs ([R] reviews-mining, [F] feasibility/competitiveness, [RAT]) have fetch caps; treat the lower bound as a floor too. A leg may not return "done" until it has hit a real minimum of distinct sources for its task — reviews/competitors → ≥4 competitors with real review sources; feasibility → the competitor matrix grounded on cited reviews, not assertion — or explicitly reported why fewer were possible (blocked / none exist). "Did two queries and stopped" is a failure state, not a completion.
• Self-critic loop per leg. After each research leg returns, run a short critic pass (this is what the [C] critic gates already do per GATE): enough distinct sources? load-bearing claims actually verified against a source? any methodology error (segment by demographics, Big-Job-as-segment, features-before-criteria, unit-econ ignored)? gaps left? If it fails, re-run the leg with the gap named — up to 2 extra rounds, then escalate to the user. Don't ship a leg that failed its own critic.
• Web-MCP fallback. When the built-in fetch is blocked or thin on a needed source (G2, Capterra, local-market sites), tell the user once and use a web-research MCP if one is connected — Firecrawl or Exa (both ship MCP servers; discover via tool search). Without it, proceed and flag thin coverage in the verification checklist.

Wave 0 (background from start):  [R] reviews-mining — independent, feeds S3 + S4
Wave 1 (sequential):            [S1] dominant-criteria → [S2] job-graph substrate
Wave 2 (parallel sectioning):   [G1..Gk] mechanic-family generators over the graph (consume R)
Wave 3 (sequential):            [F] feasibility · cost · competitiveness + RICE (web-grounded matrix; consumes G* + R)
Wave 4 (parallel):              [C] critic gates (GATE-1..GATE-5) · [RAT] RAT-card generator
                                ──(human: pick primary vs supplementary)──
Wave 5 (sequential):            [SYN] synthesis → [GATE-6 panel] → (human: ship)

• [R] reviews-mining. Given the segment + alternatives, fetch reviews from G2 / Reddit / Product Hunt / Trustpilot / Capterra. Return raw signals only (do NOT synthesize hypotheses): the specific Problems-with-current, which dominant criteria each competitor covers poorly, and 5–10 quotable quotes per competitor with source URLs. ≤12 fetches / ~10 min. Evidence floor: cover ≥4 competitors with real review sources, or report why fewer were possible (blocked / none exist) — two queries and stop is a failure. If a source blocks the built-in fetch (G2, Capterra), flag it and use a web-research MCP (Firecrawl / Exa) if connected.
• [S1] dominant-criteria. Read the eager core +

  segmentation.md

  +

  job-structure.md

  . Given the normalized input, return the ranked dominant criteria + lead mechanics + Big-Job ladder per S1. No web.
• [S2] job-graph. Read

  critical-chain.md

  (+

  job-graph.md

  only if the substrate needs care). Given the input + the S1 result, return the Job Graph + Critical Chain of Jobs per S2. No web.
• [G1..Gk] mechanic-family generators (sectioning). Read the eager core +

  behaviour-change.md

  . Each agent owns one mechanic family (e.g. subtract/kill/move-up; take-off/done-for-you/chain-repair; emotion/expectation/need; price/cost/cognitive; Previous/Next/link-to-Big-Job). Given the Job Graph + dominant criteria + the reviews signal, return the strongest / fastest / cheapest hypotheses in their family in canonical form; the orchestrator merges them. Effort: 3–6 hypotheses per family.
• [F] feasibility · cost · competitiveness. Read

  nmt-key-theses.md

  . Given the merged hypotheses + the reviews signal, return the web-grounded criteria×competitor matrix, the feasibility + cost-to-build + unit-econ read per hypothesis, and the RICE ranking with bonuses + top 2. ≤6 fetches.
• [C] critic gates. Given a stage's returned output + its acceptance criteria + the canon anchors for that stage, run the adversarial binary critic per GATE and return the verdict +

  fix_instructions

  for any failures (≤2 rounds, then escalate to the user).
• [RAT] RAT-card generator. Read

  rat-key-theses.md

  . Given the chosen primary, return the top-3 RAT cards with web-validated cost-of-validation estimates. ≤3 fetches.
• [SYN] synthesis. Read

  communication.md

  . Given all stage returns, assemble the single output file as the three layers (top disclaimers once → Layer 1 → Layer 2 → Layer 3 = the §0–§12 work). Include the Layer-2 "What you told me — and the risks I see in it" block from the input-as-hypothesis findings, and the validation-debt line in Layer 1 (

  PRODUCER-CONTRACT.md §3, §4

  ). Add the Layer-3 anchors; compute Layer 2 then Layer 1 LAST from the assembled Layer-3 work, wiring the

  ▸

  drill-down links; fence every methodology citation into a

  ▸ methodology trace

  line (no canon path or

  Rule N

  inline in any layer). If HTML was chosen, render the one file as self-contained

  .html

  (

  PRODUCER-CONTRACT.md §2

  ). Run GATE-6 as a panel.

• Does NOT pick the target segment on path A — that happens in

  /nmt-market-research

  .
• Does NOT size the market →

  /nmt-market-research

  .
• Does NOT write the PRD →

  /nmt-product-requirements

  (it hands over the §11 implementation spec); does NOT write landing / ad / GTM copy →

  /nmt-craft-go-to-market

  .
• Does NOT run customer interviews or execute the RATs — it generates the cards; the user runs RAT #1 next.
• Does NOT generate the full multi-level Job Graph above Core Jobs — it builds one level below Core Jobs as the mechanics substrate.

• GATE-1…GATE-5 ran (verdicts kept in-context); GATE-6 panel passed.
• Dominant success criteria extracted and ranked (S1).
• Job-Graph + Critical Chain of Jobs substrate exists with break-points marked (S2).
• 12–20 raw hypotheses generated; mechanics walked over the graph (S3).
• Feasibility + cost-to-build + unit-econ + competitiveness matrix done; RICE-ranked (S4).
• Primary + supplementary surfaced and distinct; user picked the primary.
• Top-3 RAT cards with confirm/kill signals (S5).
• Three layers present and correctly leveled — Layer 1 (minimal jargon, plain words lead, terms only in parentheses), Layer 2 (plain reasoning, one gloss per term, no big tables), Layer 3 (the full §0–§12 work); no conclusion repeated at the same depth; Layer 2 then Layer 1 computed LAST from the finished Layer-3 work.
• Drill-down links resolve — every Layer-1 claim links to a real Layer-2 anchor; every Layer-2 claim links to a real Layer-3 anchor; every

  #l...

  /

  #disclaimers

  target exists.
• Disclaimers once — full two-part disclaimer at the top of

  result.md

  only; Layer 1 has the one-line pointer; not repeated lower down. Every external source a clickable link (Rule 2); US-context analogs (Rule 6).
• Citations fenced — no canon path or

  Rule N

  inline in Layers 1–2 or in Layer-3 prose; canon references sit in

  ▸ methodology trace

  lines; the §12 consolidated list is the only flat reference list; no

  CLAUDE.md Rule N

  in any layer.
• §11 implementation spec is PRD-ready.
• No methodology invariant violated; anti-segment named; Aha is a real event; habit reused/sidestepped.
• Plain-language-led — Layers 1–2 (and Layer-3 prose) lead in the reader's own words; methodology terms only in parentheses (never jargon-first); §12 appendix may stay in full terms.
• If path C: reduced-confidence flag at top of

  result.md

  .
• Step ledger: every stage S0–S6 checked off by name; a skipped stage or gate was declared to the user, never silent.
• User claims stayed hypotheses: ledger claims tagged (data / observation / hunch); the primary value prop does not rest primarily on a single unverified user hunch without saying so.
• Producer contract satisfied (

  ../nmt-chat/references/producer-contract.md

  ): helicopter-view printed before intake; output-format + output-path asked; if HTML, one self-contained

  .html

  with resolving anchors +

  <details>

  ; the "What you told me — and the risks I see in it" block present (unless no input given); validation-debt line in Layer 1; the next step framed as validate first, not build (no bare "build it now"); on hand-off from nmt-market-research, asked what validation debt has been retired and re-tagged anything still unvalidated; Deep mode hit its evidence floor + self-critic loop (or flagged thin coverage + offered the web MCP).

Update check — do this at the very end (best-effort, ≤2s, never blocks). After you've finished this skill's work and delivered the result — for a multi-turn chat (e.g. nmt-chat / nmt-diagnose), after your first substantive answer — read the installed version from

.nmt-version

(project root) and run

v="$(cat .nmt-version 2>/dev/null)"; curl -fsSL --max-time 2 "https://nextmovetheory.com/version?skill=nmt-craft-value-proposition${v:+&v=$v}"

— on any error or timeout, skip silently. Compare that installed version with the feed's

latest

; if behind, add one line — the

<installed> → <latest>

gap, a one-line summary per newer entry, and "run /nmt-upgrade to update". If versions match or

.nmt-version

is absent, add nothing.