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

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 primary agent, 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 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 primary agent): read the eager core, then read each staged file the first time the run reaches its stage — not before. Deep mode: each agent reads only the files its wave needs (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:

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

Shared output guardrails: every named external source is a clickable Markdown link; use US-context analogs and the recognition test for examples; include the two-part disclaimer at the top of the result.

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

Output file (one file per run)

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

Skills-Results/{product-slug}/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.

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: language, mode, input path) ──► [no research path? → route OUT
     │                                                              to nmt-market-research → nmt-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 structured-input request, 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.

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 structured-input request

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 "Mode?  (separate from the intake-depth choice above — this is about internet)"
  - "Quick (default — fast, no internet)"
  - "Deep (subagents + web parity check)"

Q3 "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)"

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

Q5 (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. 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 structured-input request (Confirm / Correct).

Hold the normalized input in context.

S1 — Select segment + Core Jobs

If a single target segment arrives from Path A (or a clear ✅ target segment from Path B, or the one segment described on Path D) — skip the segment pick; confirm it in one line and go straight to Core-Job selection.

Otherwise present the segments on the table and ask:

Q "Which segment do we build for?"
  - [Segment 1 — one line: who they are + their dominant criteria]
  - [Segment 2 — …]
  - …
  - "None of these"

If the user picks "None of these", the skill does not go discover a new market itself — it offers the two real options: describe a different segment now (continue on the fast path), or run nmt-market-research to find and score better segments and come back. Never force a segment.

Then select the Core Jobs to design for (these are what the product performs fully — job-graph.md §2):

Q "Which Core Jobs of {segment} should the PRD cover?"
  - [Core Job 1 — When … I want to … with success criteria …]
  - [Core Job 2 — …]
  - "All of the above"
  - "I'll adjust"

Keep the focus tight — 1–3 Core Jobs. Push back on "all of everything"; focus is the subtraction of non-focal Jobs (subtraction.md §1, segmentation.md §9). Hold the chosen segment + Core Jobs (canonical form, with success criteria) in context.

S2 — Business context (only the gaps)

Gather only what an upstream artifact didn't already supply, in one structured-input request with a batch of ≤4 questions. Skip any field already known.

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

"Don't know" is fine — capture as a hypothesis (in context).

S3 — Challenge the build (the gate)

This runs before any requirement is written. Source: the-algorithm.md §4 Step 1, subtraction.md, local-vs-global-optimum.md, rat-key-theses.md §10, value-creation.md §1, §14, §17. The point is not to talk the user out of building — it is to make sure the build is the most energy-efficient way to perform the business Job, because the planning unit is the value hypothesis, not the feature.

**Question

…(truncated)