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

.

In one breath. The skill no longer re-derives segments (that is

/nmt-market-research

) or invents value (that is

/nmt-craft-value-proposition

) — it consumes their output, and it runs no research itself. With no upstream artifact it does one of two things: route the user to run

/nmt-market-research

→

/nmt-craft-value-proposition

first (the proper path), or — if the user just wants requirements fast and already knows their segment and value — take the segment + value straight from the user's description (the fast path) and skip research entirely. It then adds a "challenge the build" gate before any requirement is written — is building this even the right move, or is there a cheaper, more effective way to hit the same business goal? — and writes the PRD for whatever wins. The deliverable is a single PRD, short by default: the one-page summary (what we're building · who it's for · the moment that proves it works · the single riskiest thing to validate before building · what to build first) is what most readers need; the full functional requirements and the ~90% edge-case table sit underneath as a deeper layer for whoever builds it. Internal methodology citations are kept out of the reader's reading flow; project rule numbers never appear in the output. Canon is loaded progressively — an eager core up front, staged files only at the stage that needs them. Landing/ad/GTM copy moved to

/nmt-craft-go-to-market

; analytics and a standalone unit-economics model are out of scope (unit economics survives only as a reasoning filter).

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

GO (to validation)

, never bare

GO

; (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. This skill is the closest-to-build artifact in the chain, so the validation-debt + "validate before you build, don't build yet" framing (§4) carries the most weight here — get it right.

1. Layer 1 — What we're building (~1 page, zero methodology words — the default, what most readers need): what we're building, who it's for, the one moment that proves it works (in plain words), the single riskiest thing to validate before building, and what to build first — each line drilling down to its reasoning. Forwardable to a co-founder who's never heard of the methodology.
2. Layer 2 — The Reasoning (2–4 pages, plain English): why this build and not something else — the challenge decision, the core capabilities and why, the failure cases that matter, the riskiest assumption + cheapest probe — each linking down to the full spec.
3. Layer 3 — The Full Work (the build spec engineers and designers build against): the challenge gate, the full functional requirements, the ~90% edge-case table, target users, competitive parity, success metrics, risk handling, and an explicit out-of-scope. Behind each requirement sits the methodology trail — every feature traced from the biggest task your product does on its own, end to end (its Core Job), up to the bigger task it serves (the Big Job), through how it creates value (its value mechanic), to the bar it has to hit (its success criteria) and the moment it first feels worth it (the Aha moment) — placed along the step-by-step path the customer walks (the Critical Chain of Jobs). That trail lives in a fenced trace line, out of the reading flow.

/nmt-craft-go-to-market

• Quick (default, ~5–10 min): one Claude, no internet, no subagents. Fills the PRD directly from the loaded artifacts + reasoning.
• Deep (opt-in, longer): subagents with web access refresh competitor parity and stress-test edge cases against real reviews. See "Deep mode" at the end.

references/

8-Tools/sync/PUBLIC_MANIFEST.yml

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

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

../nmt-chat/references/Next-Move-Theory-Canon/Algorithms/the-algorithm.md

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

../nmt-chat/references/Next-Move-Theory-Canon/Next-Move-Theory/local-vs-global-optimum.md

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

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

../nmt-chat/references/Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/job-types-and-properties.md

../nmt-chat/references/Next-Move-Theory-Canon/Riskiest-Assumption-Test/rat-key-theses.md

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

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

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

../nmt-chat/references/Next-Move-Theory-Canon/Next-Move-Theory/nmt-key-theses.md

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

Path note. Use the paths above. If a file is not found there, retry with a

1-

prefix on the canon folder (

1-Next-Move-Theory-Canon/...

) — the source repo orders folders with a numeric prefix that the public repo strips.

/nmt-market-research

/nmt-craft-value-proposition

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 (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); parse multi-verb statements into the hierarchy.
• 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.

• Every feature links Core Job → Big Job AND names the value mechanic it implements (from

  value-creation-mechanics.md

  ). A feature with no Big-Job ladder and no mechanic is not a requirement — it's feature thinking (

  value-creation.md §1

  ).
• The Aha Moment is a positive-prediction-error event, never signup / login / "first action", placed as far left in the Critical Chain of Jobs as possible (

  value-creation.md §12

  ).
• The Critical Chain of Jobs is explicitly constructed per Core Job (

  critical-chain.md

  ) — functionality and edge cases are both read off it.
• Success criteria are concrete (direction + level) and translate into the success metrics (

  job-structure.md §8

  ).
• Segmentation is never re-derived here — it is consumed (Core Jobs + success criteria as the root; Big Job is motivation context, not the segmentation cut).
• The challenge step runs before any requirement is written — and the PRD is written for the winning way to perform the business Job, not necessarily the originally-specified build.

CLAUDE.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)."

• Three layers, escalating depth — state each conclusion once per layer, never twice at the same depth. Layer 1 = what we're building (headline only). Layer 2 = the reasoning in plain English. Layer 3 = the full build spec (the challenge gate table, the full functional requirements with their Core Job → Big Job → mechanic → Aha mapping, the Critical Chain of Jobs diagram, the full edge-case table, metrics, risks). A conclusion is a headline in L1, a plain sentence in L2, and a full row/section in L3 — three depths, not three copies.
• Drill-down links are mandatory. Every Layer-1 line that a reader could doubt carries a

  ▸

  link to its Layer-2 anchor; every Layer-2 claim links to the Layer-3 section that derives it. Use Markdown anchors: write

  [the riskiest thing to validate ▸](#l2-risk)

  and put

  <a id="l2-risk"></a>

  above the target. This is what makes the simple layers trustworthy — the reader can always click through to the build detail.
• Layer 1 = minimal jargon, plain words lead. Lead every line 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 helps — but never open a line with a raw term, and keep jargon to a minimum. The one "moment that proves it works" is described in plain words. Short sentences — "explain it to a smart friend."
• 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 big tables here — the full requirement, edge-case, and gate tables live in Layer 3.
• No internal methodology citations in Layers 1–2. Never write "per b2b.md §6", "per Rule 14", or any canon file path in the readable layers.
• Layer 3 may carry methodology citations — but fenced, not inline. Put canon references in a methodology trace at the end of a subsection, styled out of the reading flow, e.g.:

  <sub>▸ methodology trace. Edge cases = Critical Chain of Jobs break sites × context variations (

  critical-chain.md §7

  ;

  job-structure.md §3, §11

  ); severity by importance (

  critical-chain.md §5

  ).</sub> Never break a sentence of PRD prose with

  (critical-chain.md §7)

  ,

  (b2b.md §7)

  , or

  [the-algorithm.md §4]

  . Project-internal rule numbers (

  CLAUDE.md Rule 7

  ,

  CLAUDE.md Rule 12

  ) never appear in ANY layer of the output — they are for your reasoning only, never the reader's PRD.

• The methodology trail behind a requirement moves into the fenced trace — not the readable requirement. A non-expert reads a

  mechanic: {name}

  tag on every requirement as framework-compliance theater, not "what to build." So the readable requirement carries only what to build + acceptance criteria; the trail — main task (Core Job) → bigger task (Big Job) → how it creates value (the mechanic) → the moment it feels worth it (the Aha) — drops into the requirement's

  ▸ methodology trace

  line (kept — it is the audit trail for anyone who wants it — but out of the reading flow). Strip any canon file path from it (the mechanic name stays; the file reference does not).
• 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 lower in the file. (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. Before shipping, list every

  ▸

  target and confirm each resolves.
• Inline-gloss opaque Layer-3 table headers. A non-obvious column header (in the edge-case, requirement, or gate tables) carries a 3–6-word plain gloss right there. Don't rely on the glossary file.
• The readable requirement is clean. Per requirement, the reader sees what-to-build + acceptance criteria; the methodology mapping (

  mechanic:

  etc.) lives only in the fenced trace.

PRODUCER-CONTRACT.md §5

TMP/

.claude/

Skills-Results/{product-slug}/product-requirements/{YYYY-MM-DD_HH-MM}_{product-slug}-product-requirements-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,

  <details>

  for Layer 3 and methodology traces, source links opening in a new tab). 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 output path (intake S0), write the one file there with the same filename pattern.

utm_source=nmt-product-requirements&utm_medium=skill-artifact

PRODUCER-CONTRACT.md §1

AskUserQuestion

What you'll get: one build-ready PRD — what to build, who for, the moment that proves it works, the riskiest thing to validate first, and the full spec engineers and designers build against — in three reading depths. The steps: (1) a few questions about where you're starting from → (2) I pick up your segment + value (from upstream research, or from your description) → (3) I run a "challenge the build" gate — is building this even the right move, or is there a more efficient way to hit the same business goal? → (4) I write the PRD for whatever wins → (5) you get one document in three reading depths. Where I work vs. where you decide: I do the analysis, the challenge, and the spec. You pick the build subject and run the field validation — interviews, a fake door, a probe — before committing engineering time. I can't validate for you; I can only tell you what to check first. Two modes: Quick (default — no internet, ~5–10 min, reasoning only; good for a first spec from what you already know) · Deep (opt-in — subagents + web research, longer; refreshes competitor parity and stress-tests edge cases against real reviews; best on a top model with a web-research MCP). Honest caveat: this speeds up the thinking, not the proving. A PRD written in 10 minutes on guesses is a hypothesis to validate, not a green light to build — so before any requirement, validate the riskiest assumption.

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.

• Path D — describe it yourself (no research needed — the default for a first run). For anyone who knows roughly who they're building for and what value they're creating and just wants the requirements. Describe it in plain sentences — no special format required. Collect, by description or dictation: the product (a sentence or two) + a URL if there is one; who it's for (the segment) and what makes them that group — a behaviour or characteristic, not demographics like age or income; the bigger result they're really after (their Big Job) and how they'd know it worked (their success criteria); in a sentence each, the 1–3 main tasks this customer is trying to get done with the product (its Core Jobs) — I'll shape these into the formal version internally; the value — what makes it worth switching, and roughly how (this stands in for a

  /nmt-craft-value-proposition

  run); a few known alternatives if you have them (what they use today); and the business goal. I fix the grammar behind the scenes (splitting any task that's really two, dropping demographics that aren't causal, turning adjective-value into concrete value). Then straight into S1→S5. The result flags up front that it was generated from a described segment + value, not a research-backed one.
• Path A — reuse a

  /nmt-craft-value-proposition

  result (richest input). Read it. Its implementation spec already carries the product shape, the feature table, the step-by-step path and where the moment-it-feels-worth-it fires, cost-to-build & cheapest probe, unit-econ direction, and who it's explicitly not for — plus the target segment, the bigger result they're after (Big Job), competitors, proof, and the riskiest-assumption cards in the body. Segments AND value are both present. Most of S1/S2 is already answered; confirm rather than re-ask, then go to S3.
• Path B — reuse a

  /nmt-market-research

  result. Read it. Parse the target segment(s) (✅/⚠️), their main tasks + success criteria, bigger results they're after, competitors (direct/indirect/turnkey), where you win, and the action-first riskiest-assumption list — carry all of it forward, never regenerate it. The value layer is not yet crafted, so say so: "You have segments but no crafted value proposition. Strongly recommended: run

  /nmt-craft-value-proposition

  on the target segment first — the PRD is much sharper from a real value hypothesis. Run it now, or proceed using the market-research differentiation hypothesis as the value direction?" If the user proceeds, use it as the value direction; flag the reduced confidence at the top of the PRD.
• Hand-off debt — ask what has since been validated (Paths A/B only —

  PRODUCER-CONTRACT.md §4c

  ). The upstream artifact carried its own list of things still unvalidated (its risk rows — segment, willingness-to-pay, value, channel assumptions). That debt travels down the chain; it is not silently dropped. Because this PRD is the closest-to-build artifact, ask once before building: "Your {market-research / value-proposition} result rested on these unvalidated assumptions: {list them}. Which of these have you since checked in the field, and what did you find?" Re-tag anything still unvalidated — it carries into this PRD's risk section (§7) and counts toward this PRD's validation debt (Layer 1), with the cheapest probe pointed at it. Anything the user confirms was validated is marked as such and drops out of the debt count.
• Path C — no research yet, but you want to do it first (route out). Reply: "The right order is

  /nmt-market-research

  →

  /nmt-craft-value-proposition

  → back here. Run

  /nmt-market-research

  first (it finds and scores the segments), then

  /nmt-craft-value-proposition

  (it builds the value hypothesis + a build-ready spec), then return and pick Path A. Want me to open the

  /nmt-market-research

  input prompt now?" Hand off and stop — this skill does not size markets or discover segments. (If you'd rather not wait, Path D lets you describe the segment and value and build now.)

• Materials. Ask once: "Any files or folders with material I should use — a Notion export (markdown), past research, interview notes, an existing spec, your current site?" Read what's given; tag everything taken from it [user data] in-context — and never silently carry a user's existing positioning, copy, or feature list into the PRD as a settled decision: confirm first that it should carry over (it may be exactly what the challenge step should challenge).
• User-claims ledger + input-as-hypothesis gate (

  PRODUCER-CONTRACT.md §3

  ). Collect every strong factual claim in the user's input — and every load-bearing input from the upstream artifact and the uploaded materials (a deck, a landing page, a codebase, the manually-described segment + value on Path D) — into an in-context ledger. All of it is hypothesis, not fact — a landing page is the team's belief about value, not proof customers want it; a stated segment + value can be the team's projection of the customer's Job rather than the customer's real one (the most expensive error). Tag each as data (measured / documented), observation (seen in interviews, sales), or hunch (belief, intuition — the default for anything from a deck / landing / the idea description). Actively hunt the risks inside each load-bearing input (don't just record it): is this customer-validated, or the team's belief about the customer? Does the stated Job / segment look like the customer's real Job, or the team's projection of it? Any internal contradictions, or guesses dressed as data? Hold the findings in context — they become the "What you told me — and the risks I see in it" block in Layer 2 (see the Layer-2 template), with the single worst one surfaced in Layer 1.
• Hard gate (

  PRODUCER-CONTRACT.md §3c

  ). No PRD scope, Core-Job selection, or challenge verdict may rest primarily on an unvalidated user input without the PRD saying so explicitly and pointing a RAT row at it. If the build scope leans on a Job or value taken from the user's materials and not confirmed by customer evidence, that is named in §7 as the single most expensive risk, with the cheapest falsifying test attached — and it is the "single riskiest thing to validate BEFORE building" in Layer 1.
• Direction confirmation. Before S1, play the understanding back in one short block — "Here's what I understood: {what we're building, for whom, the business goal, what's already decided vs open}" — and confirm via one

  AskUserQuestion

  (Confirm / Correct).

AskUserQuestion

• Business goal / business Job — why are we building this? (launch / grow an existing product / new feature / expand to a new segment). This is the anchor the S3 challenge ladders up from.
• Constraints — team, budget, build horizon (<2 wks / 1–2 mo / 3–6 mo / 6+ mo). Sets MVP-vs-full scope and the cheapest-probe framing.
• Stage / traction — idea on paper / interviews done / early users / live with traffic. Sets PMF context (

  the-algorithm.md §5

  ).
• Product type & monetization — SaaS / mobile / service / marketplace / course; subscription / one-off / freemium / lead-gen. (B2B? → load

  b2b.md

  at the edge-case stage for the role-chain edge cases — not before.)

the-algorithm.md §4 Step 1

subtraction.md

local-vs-global-optimum.md

rat-key-theses.md §10

value-creation.md §1, §14, §17

PRODUCER-CONTRACT.md §3

1. Ladder the business goal up (5 Whys). Why build this? → in order to do what? → climb 3–5 levels (feature → conversion → sales → margin → the strategic goal). Name the real business Job the build is meant to serve. The thing handed to you is frequently a mis-set goal; analyzing how to hit a mis-set goal is the most expensive early waste (

   the-algorithm.md

   Step 1).
2. Subtraction-first. Ask the one question that travels across pillars: "What can we remove from this product / segment / chain / assumption-stack that would produce a comparable or larger effect for less cost?" Hold the invisible-product asymptote: "What would it look like for the customer to reach this outcome with no product to interact with at all?" (

   subtraction.md §2–§3

   ).
3. Local-vs-global check. Is the proposed build an additive local-optimum move (improve the current product/segment/model — low risk, capped return) when a global-optimum move (move-up-a-level, change segment, change business model, capture Previous/Next Job) would return multiplicatively more? Name the choice explicitly; don't drift into local by default (

   local-vs-global-optimum.md

   ).
4. Generate the more-effective ways. Walk the value-creation mechanics over the segment's Job Graph and generate 2–4 alternatives to building the thing as specified — each one a concrete way to perform the business Job more energy-efficiently. Lead with the two dominant mechanics (move up a level, kill a Job) and the cheapest-probe forms (concierge, no-code, done-for-you, partner, capture the Previous Job, "do nothing"). For each alternative state: the mechanic, what it removes/adds, cost-to-build vs. the original, a unit-economics-direction sanity check (does the value convert to margin?), and the riskiest assumption it carries (RAT drop-it: which alternative removes risk rather than adding it).

Q "Here's the build as specified, plus {N} potentially more-effective ways to hit
   the business Job '{laddered business Job}'. Which do we write the PRD for?"
  - "Build it as specified"           [+ one line on why it's the right call]
  - "{More-effective way 1}"           [mechanic — what it removes — cost vs. original]
  - "{More-effective way 2}"           […]
  - "Blend — I'll describe"

PRODUCER-CONTRACT.md §4

GO (to validation)

GO

Keep this proportionate. For a small, well-validated feature on a working product the challenge may be one paragraph that confirms the build; for a from-scratch product it is the highest-leverage step in the run. Do not manufacture alternatives for symmetry — if the specified build genuinely is the most efficient way, say so and move on (

CLAUDE.md

Rule 12).

• Path A (nmt-craft-value-proposition input): the §11 implementation spec already carries the Critical Chain of Jobs & Aha placement — consume it, don't rebuild it. Extend it only with what the PRD needs on top: the shape of each chain segment (AND-parallel / OR-alternative / conditional) and the break sites (hand-offs, cycles, slowest link, external-interruption points). If the S3 challenge changed the build subject, re-anchor the inherited chain on the new subject instead of starting over.
• Paths B / D (no value-prop chain): construct the Critical Chain of Jobs from scratch per selected Core Job — the sequence of Micro Jobs that must all complete for the Big Job to land (

  critical-chain.md §1–§2

  ) — with shapes, break sites, the Aha-Moment position and how far left it can be shifted.

• Level 1 — What we're building (1 page, plain words): what it is, who it's for, the moment that proves it works, the one thing to validate first, what to build first. Most readers stop here. jump ▸
• Level 2 — The Reasoning (plain English): why this build and not something else — the core capabilities and why, the failure cases that matter, the riskiest assumption. jump ▸
• Level 3 — The Full Work (the build spec): every requirement with acceptance criteria, the flow, the ~90% edge-case table, metrics, risks — what engineers and designers build against. jump ▸

undefined

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

Validation debt: this PRD stands on {N} unvalidated assumptions — {M} of them fatal (would sink the build if wrong). Validate the fatal ones in the field before committing engineering time. see them ▸ <sub>N = risky assumptions in the §7 risk table (incl. any unretired upstream debt carried in via S0); M = those that kill the build if wrong. A Quick run on a manually-described segment + value has high debt — say so honestly (

PRODUCER-CONTRACT.md §4

). A PRD written fast on guesses looks as convincing as one built on 8 interviews; this line is what keeps it honest.</sub>

• The business goal laddered up (5 Whys) to the real business Job it serves.
• What we could remove, and the bigger-move check — local (improve the current thing) vs. a global move that returns more.
• The 2–4 more-effective ways generated, and which one won (the locked build subject), in a short table:

_{▸ methodology trace. {fence the canon refs for the challenge here.}}

• What we're building (the build subject locked in the challenge gate) and the business Job it serves.
• Target segment(s) + the selected Core Jobs (canonical form, with success criteria).
• The Aha moment per segment — the moment the product first clearly beats what the customer expected, where it fires on the step-by-step path the customer walks (the Critical Chain of Jobs), how far left it's shifted. (Never signup/login.)
• If the challenge changed the approach: one line on what was not built and why.

• Per segment: causal criteria; the Core Jobs they hire us for; their dominant success criteria (direction + level); the Big Job(s) above (motivation).
• B2B: business Job and personal Job per relevant role; the role chain.

_{▸ methodology trace. {fence the canon refs — segmentation root, B2B role-chain — here.}}

• The Critical Chain of Jobs (the Micro-Job sequence from §4.0, shape marked) — render the chain as a small diagram or ordered list with break sites marked.
• Requirements phrased from the user's side — "User can {Micro Job}" — each with acceptance criteria = the success criteria (direction + level). This — what to build + acceptance criteria — is all the reader sees on the requirement itself.
• The mapping moves into the fenced trace, not onto the requirement line. The

  Core Job → Big Job · mechanic: {mechanic name} · Aha: {how this requirement moves the customer toward the moment}

  mapping is kept (it is the audit trail) but lives in the

  ▸ methodology trace

  below, so the readable requirement stays "what to build," not framework bookkeeping. Name the mechanic; do not append any canon file path.
• Onboarding → value activation: the shortest path to the first Aha Moment; what to remove/simplify to shift it left; the Aha validity check (what does the user predict here? what do they get? is the actual better than the prediction? — if nothing is surprising, it isn't an Aha Moment).
• No feature dilution: every requirement serves the target segment, or is moved to §7 deferred.

<sub>▸ methodology trace. The per-requirement

Core Job → Big Job · mechanic · Aha

mappings go here (one per requirement), plus the canon refs — value formula, criteria→mechanics, Aha placement.</sub>

• (a) Context variations — same expected outcome, different context → different success criteria → effectively a different Job. Enumerate the contexts the segment + adjacent users actually hit: new vs returning user; B2B roles; regulatory contexts (HIPAA / FERPA / state-by-state); locale / device / language; scale (0 items / 1 / many / 10,000); free vs paid tier; first-time (Orientation-Job-heavy) vs Nth-time.
• (b) break sites on that path — hand-offs (ownership ambiguity, latency, information loss), cycles (return-for-rework), the slowest link, external interruptions (a higher-priority task bursts in; the bar changes mid-walk; a competitor surfaces mid-walk).
• (c) forced, unwanted work when something fails (Tax Jobs) — extra work pushed onto the customer when a step in the path fails; each is a bad surprise (a problem) and a churn/abandonment trigger.
• (d) job-type branches — the researching-and-choosing step for first-timers (an Orientation Job); anxiety states (Emotional Jobs); a task done for or with someone else (a Viral Job); steps in the path that exist only for a sub-context.
• (e) B2B role-chain breaks (if B2B) — breaks at role boundaries, mostly personal-Job failures (IT security veto, procurement/legal late stalls).
• Standard categories, framed as chain-breaks: empty/oversized/malformed input; no/slow/lost network; concurrency & conflicting operations; auth & permissions; payments (cancelled / partial refund / lapsed sub / double charge); security (injection, unauthorized access, rate limits).

| # | Use-case / context | Where in the Critical Chain of Jobs | What breaks (the Problem / Tax Job) | Severity (Critical/High/Med/Low) | Requirement to handle it |

_{▸ methodology trace. {fence the canon refs — break sites, context→criteria, Tax Jobs, severity by importance — here.}}

• Functionality that must at least match competitors (from the upstream competitor set).
• Functionality competitors close poorly = our wedge (the underserved success-criterion intersection).
• (Deep mode refreshes this against live competitor sites + reviews.)

• Per Core Job: the success criteria translated into measurable activation / value-delivery metrics (the criteria are the metric set).
• Aha-Moment rate (share of new users who reach it, and how far left it fires).
• North Star: the target segment performing the Core Job at criteria, repeatedly.

• Risks: the RAT carried from upstream (or generated here) — for each, how the PRD minimizes/accounts for it, and the single riskiest assumption to validate (cheaply) before the build (kill the product, don't launch it; the MVP is a probe, name what it tests).
• Who this is NOT for — out of scope: who this is explicitly NOT for (2–3 groups); Jobs/segments deliberately subtracted to hold focus; features deferred to a later phase (the non-focal Jobs identified earlier).

_{▸ methodology trace. {fence the canon refs — RAT, drop-it exercise, MVP-as-probe — here.}}

1. No segment re-derivation — the segment/Core Jobs were consumed from an upstream artifact or taken from the user's description; never discovered, sized, or scored inside this skill.
2. Challenge ran first — the business goal was laddered, subtraction-first asked, local-vs-global named, and the PRD is written for the winning build subject.
3. Every feature ladders Core Job → Big Job AND names a value mechanic — no bare features.
4. Aha Moment is a real positive-prediction-error event, placed as far left as the chain allows — not signup/login.
5. The Critical Chain of Jobs is explicit per Core Job, with shape and break sites marked.
6. Edge cases are chain-break-driven and context-spanning, ~90% coverage, severity by importance — not a generic QA list.
7. Success criteria are concrete (direction + level) and map to the success metrics.
8. Out-of-scope names the anti-segment and the subtracted Jobs — focus is visible.
9. Disclaimers present; external sources are clickable links; US-context analogs; no PPE/NPE (

   CLAUDE.md

   Rules 2, 3, 6, 19, 22).
10. Step ledger ran — every stage S0–S5 checked off by name; a skipped stage (e.g., the challenge collapsed to a one-line confirm) was declared, never silent.
11. User claims stayed hypotheses — ledger claims tagged (data / observation / hunch); no requirement or challenge-verdict rests primarily on a single unverified user hunch without saying so; nothing from the user's existing materials was carried into the PRD as a settled decision without confirmation.

• Plain-language-led — the PRD leads in the reader's own words; methodology terms only in parentheses (never jargon-first); Layer 3 may stay in full terms.
• Three layers present and correctly leveled — Layer 1 (minimal jargon, plain words lead, terms only in parentheses, forwardable), Layer 2 (plain reasoning, terms glossed), Layer 3 (the full build spec). No conclusion is repeated at the same depth across layers.
• Drill-down links resolve and are unique — every Layer-1 line 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.
• Readable requirement is clean — per requirement the reader sees what-to-build + acceptance criteria only; the

  Core Job → Big Job · mechanic · Aha

  mapping lives in the fenced

  ▸ methodology trace

  . 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; Layer 3 does not repeat the block.
• 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. No

  CLAUDE.md Rule N

  appears anywhere in the output, in any layer. The mechanic mapping carries the mechanic name but no canon file path.
• Step ledger ran — every stage S0–S5 checked off by name; any skip was declared, never silent.
• Producer contract satisfied (

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

  ) — helicopter-view printed before the first question (§1); output-format and output-path asked in intake, and the file written in the chosen format at the chosen location (§2, §5); all user input + the upstream artifact treated as hypothesis, the "What you told me — and the risks I see in it" block present, and no scope rests primarily on an unvalidated input without saying so + a RAT row (§3); the validation-debt line present in Layer 1 and any GO-style build verdict written as

  GO (to validation)

  , framed as "validate first, then build" (§4); on Paths A/B the hand-off asked what upstream debt was retired and re-tagged the rest (§4c); in Deep mode each web leg met its evidence floor + passed its self-critic, with the web-MCP fallback offered when fetch was blocked (§6).

• Evidence floor (not just the cap). Treat each web leg's lower bound as a floor, not only a ceiling: the PARITY leg and the EDGE review-mining leg may not return "done" until each has hit a real minimum of distinct sources for its task or explicitly reported why fewer were possible (blocked, none exist). "Made two queries and stopped" is a failure state, not a completion — the leg re-runs.
• Self-critic loop on each leg. After PARITY and EDGE return, the CRITIC runs a short pass on each: enough distinct sources? are the load-bearing parity / edge-case claims actually verified against a source? any methodology error (a feature with no Core Job → Big Job ladder or no mechanic; an Aha set to signup/login; edge cases that are a generic QA list, not Critical Chain of Jobs breaks)? gaps left? If a leg fails its critic, re-run it with the gap named — up to 2 extra rounds; don't assemble the PRD on 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 competitor sites), tell the user once and use a web-research MCP if one is connected:

  Some sources (e.g., G2, Capterra) block the built-in fetch. For fuller Deep parity and edge-case mining, enable a web-research MCP — Firecrawl or Exa (both ship MCP servers) — and I'll use it. Without it, I'll note where coverage was thin.

  If such an MCP is connected (discoverable via tool search), prefer it for blocked sources; otherwise proceed and flag thin coverage in the verification checklist.

• Does not re-derive segments or size markets →

  /nmt-market-research

  .
• Does not invent the value proposition or pick the target segment →

  /nmt-craft-value-proposition

  (it consumes the §11 implementation spec).
• Does not write landing, ad, or GTM/growth copy →

  /nmt-craft-go-to-market

  .
• Does not produce an analytics plan (out of scope this version) or a standalone unit-economics model (unit economics is used only as a reasoning filter in S3/ranking).
• Does not run interviews or execute the RATs — it names the riskiest assumption to validate; the user runs it next.
• Quick mode: no internet, no subagents.

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-product-requirements${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.