zamesin/next-move-theory-canon-and-skills/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 Codex 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 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 Codex 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.