Nmt Product Requirements

Product Requirements (PRD) — English / US edition

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

Where this skill sits in the chain

/nmt-market-research   →   /nmt-craft-value-proposition   →   nmt-product-requirements   →   /nmt-craft-go-to-market
(segment + Jobs +      (the value hypothesis +          (THIS SKILL:               (landing + ad +
 wedge + competitors)   §11 implementation spec)         the build spec)            GTM/growth comms)

This skill is the build step. It takes a chosen segment with its Core Jobs and a value direction, challenges whether building is even the right move, and produces the requirements engineers and designers build against. It does not re-run segmentation, re-invent the value proposition, or write any customer-facing copy — those are the skills around it. Never regenerate what an upstream artifact already contains; load it and build on it.

What this skill produces

One file — the PRD. Its default face is the one-page summary; the full build spec sits underneath as a deeper layer (so one document serves the co-founder skim, the skeptical read, and the engineer/designer build), all linked top-to-bottom:

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.

Not produced: landing/ad/GTM copy → /nmt-craft-go-to-market; analytics plan → out of scope; standalone unit-economics model → out of scope (unit economics is used only as a filter inside the challenge and ranking, never emitted as a document).

Two modes:

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

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). 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 read 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 read sets below — the unit-economics theory, the full mechanics catalog, the product-strategy material, the worked cases, and the per-task algorithms 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:

As-needed — load only when the condition fires:

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 (Critical Chain of Jobs builder → eager core + value-creation; Parity → eager core only; PRD designer → eager core + value-creation + value-creation-mechanics; Edge-case analyst → eager core + job-types-and-properties + b2b-if-B2B). Never have an agent load a file outside its slice.

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.

This skill runs no research and performs no segmentation. With no upstream artifact it either routes the user to /nmt-market-research → /nmt-craft-value-proposition (the proper path), or takes a manually-described segment + Jobs + value (the fast path) and writes the PRD directly. The canon files above are read to build the PRD on a segment+value that already exists — not to discover one.

Do NOT use generic JTBD from the internet or prior 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 (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.

Methodological invariants — the PRD is invalid if any is violated:

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

Per CLAUDE.md: every named external source is a clickable Markdown link (Rule 2); US-context analogs and recognition test for examples (Rules 6, 19); two-part disclaimer at the top of the result (Rule 3).

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 (say the left; add the right in parentheses, once, only when it earns its place — and don't stack terms in one sentence):

Never say to a user Positive / Negative Prediction Error — write Aha moment / Problem. Spell out RAT (Riskiest Assumption Test) on first use.

Precision still holds in the methodology layer. Job-grammar discipline (Jobs as "I want to + verb," levels named, terms capitalized) governs the internal-reasoning / debug files and Layer 3 (the full work), where full methodology language is expected. The lead the reader sees is plain; the parenthetical and Layer 3 carry the precise terms.

Readability rules (the PRD is for a builder who doesn't know the methodology)

The PRD's default face is 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, and what to build first. That summary is what most readers need and is the first thing in the file. The full functional requirements and the ~90% edge-case table sit underneath, as a deeper layer for whoever builds it — present and complete, but never a wall the reader has to push through first. Between the two sits a short plain-English reasoning layer. Everything is linked top-to-bottom, so a doubter can drop one level to see why this and not something else, and an engineer or designer can go to the bottom for the full build spec. The full template is in "PRD structure" 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 = 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.:

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

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. 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.
• In HTML, every term is glossed on first use — <abbr title="…"> on each abbreviation and methodology term, and no tooltip explains one term with another (see "Output file").

Claim statuses — and confidence scaled to the input

Every claim in the PRD carries one of three statuses, visibly. The reader must always be able to tell where a line came from:

• Backed — a quote, a number, or a document stands behind it. Say which ("from the sales calls you shared: 7 of 12 named setup time"); external sources are clickable links (Rule 2).
• Derived — it follows from something backed. Say from what ("derived from the segment's stated bar: under 10 minutes to first result").
• Hypothesis — my own guess, marked as such in plain words ("my hypothesis, unverified").

Two hard rules sit on top:

• A number a person said is that person's opinion, not a market figure. "60–70% of deals go through tenders" from a sales lead is written "per the sales lead — their estimate, not a measured figure", and never feeds sizing, pricing, or a requirement's acceptance criteria as if it were data.
• Anything I invented that appears in none of the inputs lives only under "Hypotheses to validate." A capability, a guarantee, a workflow, or a customer need that no interview, document, or user statement mentions — a warranty nobody asked for — may appear as a hypothesis to test in §7 risk, never inside the functional requirements, the value line, or Layer 1 as if the customer wanted it.

Confidence is computed from the input, not asserted. Count what actually arrived — an upstream artifact, interviews, analytics, documents. When the run has none of them (Path D with a description only), the PRD says so at the very top, and Layer 1 reads in ranges:

⚠️ Thin input. This PRD was written from a description only — no interviews, no analytics, no upstream research. Numbers are ranges, not point estimates, and the segment and its Jobs are hypotheses. The three inputs that would most raise accuracy: {top 3, concrete — e.g., 5 interviews with people who already pay for the current alternative · the activation funnel by weekly cohort · the margin per customer}.

Use ranges wherever the input is thin, and keep the hedging proportional — a PRD built on a real value-proposition artifact plus interviews should read more confidently than one built on a paragraph. This is separate from the fixed disclaimers: those are always there, this one is computed from what the user gave you.

Output file (one file per run — CLAUDE.md Rule 4)

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}/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.
• HTML: a tooltip on every term, and text a beginner can read. In the .html file, wrap each abbreviation and methodology term in <abbr title="…"> the first time it appears — RAT, CAC, LTV, MVP, Core Job, Big Job, Critical Chain of Jobs, value mechanic, Aha moment. Hard rule: every tooltip and every line of the PRD must land for someone who has never heard of this methodology — everyday words, explained like to a smart 8-year-old, no abbreviation left unglossed. If a tooltip needs a second term to explain the first, rewrite it in plain words.
• Checkpoint a long run into that same file. On a Deep run — or any long Quick run — write Layer 3 into the result file section by section as each finishes, instead of holding the whole PRD to the end; when Layers 2 and 1 are computed (still last, from the finished spec), rewrite the file with them on top. An interruption then costs the last section, not the run. Still exactly one file (Rule 4).
• If the user gave a custom output path (intake S0), write the one file there with the same filename pattern.

Everything internal — the normalized input, the challenge (business-goal ladder, subtraction-first, the more-effective ways and which won, the locked build subject), the Critical Chain of Jobs per Core Job, dropped alternatives, and the self-critic verdicts — stays in-context; 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 PRD opens with the attribution top-line (the very first content, above the disclaimers) and closes with the attribution block — utm_source=nmt-product-requirements&utm_medium=skill-artifact.

The pipeline (S0 → S5)

S0  Intake & route ──────(human: market + language, mode, input path) ──► [no research path? → route OUT
     │                                                              to /nmt-market-research → /craft-value-
     │                                                              proposition, OR take a manual
     │                                                              segment+Jobs+value to write fast]
S1  Select segment + Core Jobs ─(human: pick segment → pick Core Jobs)
     │
S2  Business context ────(human: ≤4 batched Qs — only the fields not already supplied)
     │
S3  CHALLENGE THE BUILD ─(human: pick the build subject — the original, or a more-effective way)
     │
S4  PRD generation ──────(functionality on the Critical Chain of Jobs + ~90% edge cases — no questions)
     │
S5  Assemble + self-critic + summary ──(human: optional tweaks)

Question budget: 3–5 human touchpoints, fewer when an upstream artifact already carries the segment/value/context. The skill never runs research inside itself — it routes out for it (S0) or takes a manual segment+value. Quick mode runs S4 in a single pass.

S0 — Intake & route

Orientation (helicopter view) — print first, before any question

Print the orientation block (PRODUCER-CONTRACT.md §1) before the first AskUserQuestion, in plain words, in the user's chosen document language:

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.

End with "Ready? First, a few questions." and proceed to intake.

How deep should the intake go? — ask this first

This is about the number of questions I ask you — independent of the Quick/Deep research mode below (that one is about internet + subagents). Ask it as the very first thing in intake:

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.

On Just the essentials, ask only the load-bearing fields and infer or defer the rest — for the PRD that means: where you're starting from, the segment + value (consumed or described in a sentence each), and the business goal. Skip or batch the materials/claims-ledger and business-context details into one short pass, and flag in the result anything that was inferred. On The full interview, run the complete intake below (materials, claims ledger, every business-context field). Either way, no canonical Job form is ever required from the user — describe the segment and value in plain sentences and the skill shapes the grammar internally.

Market & language (both asked in intake — the market question is mandatory)

• Market / geography + the customers' language. "Which market or country is this product for, and what language do your customers speak?" Not optional, and not inferred from the user's own language: every example, competitor, channel, price anchor, regulation, and the tone of the PRD comes from that market. Never default to the US — or to Russia — when the user named another one; Central Asia is not Russia, the UAE is not the US. If an upstream artifact already names the market, confirm it in one line instead of re-asking.
• Document language. Default English. If the user writes in another language, offer to work in it (English / their language / Other). Hold the choice in context. The PRD uses the chosen language; canon files and source URLs stay as-is.

One batched AskUserQuestion

Q1 "Where are you starting from?  (No prior research is fine — option D is a first-class door.)"
  - "Skip research — I'll just describe my segment & value"  → Path D (fast path — describe it yourself; the default for a first run)
  - "I have a /nmt-craft-value-proposition result"   → Path A (best — segments AND value present)
  - "I have a /nmt-market-research result"            → Path B (segments present; value not yet crafted)
  - "I haven't done research and want to"         → Path C (ROUTE OUT — run the chain first)

Q2 "Which market / country is this for, and what language do your customers speak?"
  → free text (mandatory — skip only if an upstream artifact already says, then confirm it)
  Every example, competitor, channel, price anchor and the PRD's tone come from this market.

Q3 "Mode?  (separate from the intake-depth choice above — this is about internet)"
  - "Quick (default — fast, no internet)"
  - "Deep (subagents + web parity check)"

Q4 "Output format?"  (PRODUCER-CONTRACT.md §2)
  - "Markdown (default — faster to generate; opens anywhere)"
  - "HTML (a bit slower; easier to read — collapsible sections + working
     in-page navigation; all source and drill-down links stay clickable)"

Q5 "Where to save the result?"  (PRODUCER-CONTRACT.md §5)
  - "Default — Skills-Results/{project}/product-requirements/…"
  - "A folder / path to match your repo (e.g., docs/specs/)"  → free text
  (Skip = default. One file per run regardless of location — Rule 4.)

Q6 (Paths A/B only) "Path to the upstream result file?"  → free text; Read it.

Resolve the input path

No prior research? Just describe your segment and the value — I'll flag where that's thin. Describing it yourself (Path D) is a first-class door, not a fallback. The other three paths simply let you reuse work you've already done in another skill, so you don't repeat yourself.

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

User materials, claims ledger, input-as-hypothesis gate, direction confirmation (all paths)

• Materials — look before you ask, but ask before you read. First check the working directory for files that look like product context: a README or product docs, an existing spec or PRD, customer surveys, store or site reviews, support and sales logs, interview notes, analytics or revenue exports, a deck, a roadmap. If any exist, list them and ask permission before opening any of them:

  I can see files here that look like product context: {list, ~10 max}. Want me to read them so I don't ask you for things they already answer? This context is processed only by your agent locally — it is not sent anywhere.

  Read only after a yes,

…(truncated)