In one breath. Before any research runs, a short intake closes the gaps that change the research: a few clarifying questions (with "I don't have this info" as a valid answer), any materials you already have read in, your inputs held as hypotheses rather than facts, and a quick direction confirmation. The deliverable is a decision: a one-page answer with a GO (to validation) / NARROW / PIVOT verdict, the customer segments scored on the four go/no-go questions (the selection screen), the make-or-break risk and how to test it, and ranked strategic options (including other markets the same idea could fit). Quick mode sizes honestly (one calculation, assumptions named); the 3-method averaging runs only in Deep mode, on real sources.

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.

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

.

1. Layer 1 — The Answer (~1 page, zero methodology words, the default — this is the whole answer): the verdict, who to sell to first, why, the make-or-break risk, the next step, and how big — each line drilling down to its reasoning if you want it. Readable in ~60 seconds by someone who's never heard of the methodology; forwardable to a co-founder or investor. Most readers stop here.
2. Layer 2 — The Reasoning (opt-in, 2–4 pages, plain English): how we got here for each Layer-1 claim — verdict logic, how the buyer was found, where we win, the ranked risks, the plan — each linking down to the full work.
3. Layer 3 — The Full Work (opt-in, the detailed report + appendix): market snapshot, a Map of Segments with every segment expanded, the differentiation hypothesis, the strategic recommendation with alternative Big-Job markets, the action-first risk plan, and the sizing appendix.

• Quick (default, ~3–5 min): no internet, no subagents. One Claude fills the templates directly from reasoning.
• Deep (opt-in, longer): a team of subagents with web access fills the same templates with real competitor, review, and sourcing data. See "Deep mode pipeline" at the end.

references/

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

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

../nmt-chat/references/Next-Move-Theory-Canon/Riskiest-Assumption-Test/rat-key-theses.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/value-creation-mechanics.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.

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.

• I want to + verb

  is the primary element of an eight-element Job, not the whole Job.
• 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.

• Segments are formed by similar Core Jobs sharing similar success criteria — never by demographics, industry, or Big Job as the primary cut.
• A "real segmentation criterion" is a cause (a behaviour or characteristic), never a paraphrased value or a consequence.
• Competitors are defined by Jobs, not categories (direct on the Core Job; indirect on the Big Job, including "do nothing" and non-obvious substitutes).
• Features follow from success criteria and a chosen value mechanic — not the reverse.
• Every segment is scored on the selection screen (below); the focus pick is justified on it.

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

PRODUCER-CONTRACT.md §5

TMP/

.claude/

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

  collapsing Layer 2 and Layer 3 — both opt-in below the one-page answer — plus 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 where the short answer leads and the deeper layers are collapsed by default. Never write both; one file per run.
• If the user gave a custom path, write the one file there with the same filename pattern.

• {YYYY-MM-DD_HH-MM}

  (24h local time) makes each run's file unique; reruns never overwrite.
• Everything internal — what the user provided, discarded hypotheses, antisegment checks, Big-Job validation, the full sizing tables, milestone notes, and all methodology citations (which never appear in the user-facing report — see "Readability") — stays in-context, never in a separate file.
• Deep mode adds no intermediate files: subagents return their results in-message and the orchestrator writes the one file (see the Deep pipeline section).

utm_source=nmt-market-research&utm_medium=skill-artifact

PRODUCER-CONTRACT.md §1

What you'll get: one report — a GO (to validation) / NARROW / PIVOT decision, the segment to sell to first, why, the make-or-break risk, and how big the market is. The steps: (1) a few questions about your idea → (2) I find and score the customer segments → (3) I size the market → (4) I pick where you can win and rank your strategic options → (5) you get one report in three reading depths. Where I work vs. where you decide: I do the analysis and the hypotheses. You pick the direction and run the field validation — interviews, sales, tests. I can't validate for you; I can only tell you what to check first. Two modes: Quick (default — no internet, ~3–5 min, reasoning only; good for a first cut and "did I miss something") · Deep (opt-in — subagents + web research, longer; real competitor/market/review data; best on a top model with a web-research MCP). Honest caveat: this speeds up the thinking, not the proving. Every number and segment is a hypothesis until you check it in the field.

AskUserQuestion

First — how deep should I go? Pick one:

• Just the essentials — I ask the 3–4 questions that matter most, then deliver. Best for a fast first pass or when you're still exploring.
• The full interview — I walk you through everything so we cover the most blind spots and you get the highest-confidence result. Best when the decision is expensive.

• Just the essentials → ask only the 3–4 highest-value questions — what the product is, who you think buys it, and your goal (Step 1 stream + the stage/country/business-type basics) — then infer or skip the rest. Don't run the assets-and-constraints capture (Step 4) or the user-claims ledger (Step 6) as separate steps up front; infer assets from the idea stream, treat the inputs as hypotheses silently, and you can surface a claims-and-risks pass after the first draft if it's worth it.
• The full interview → run the complete multi-batch intake below (Steps 1–7), including the assets-and-constraints capture and the user-claims ledger.

AskUserQuestion

Describe your idea as a stream — what it is, who it's for, what it does for them, and anything you already have going for it (technology, team, partners, traction).

• Mode — Quick (default; fast; no internet) / Deep (subagents + web research). (This is the research mode — separate from the intake-depth fork in Step 0.)
• Output format (

  PRODUCER-CONTRACT.md §2

  ) — Markdown (default; faster) / HTML (a bit slower; easier to read — collapsible sections + working in-page navigation; all source and drill-down links stay clickable).
• Stage — Idea / MVP / Launched / Scaling.
• Country / market — United States / United Kingdom / Russia-CIS / Global-English / Other.
• Business type — B2C / B2B / Both B2C and B2B / B2B2C (true channel-through-business only).

• Project context & materials — path / URL / Skip. Name what counts: a folder or files with anything you already have — a Notion export (markdown), spreadsheets, past research, interview notes, a strategy doc, your current site. (Quick: local paths via

  Read

  ; Deep: also

  WebFetch

  .) Everything taken from the user's materials is tagged [user data] in-context and cited as such in the report.
• Hypothesized segments — "Yes, I'll describe" / "I don't know — find them" (default) / Skip.
• Known competitors — "Yes, I'll list them" / "I don't know — find them" (default) / Skip.
• Ambition — "I'll describe" (revenue / margin / timeframe) / Skip.
• Where to save the result (

  PRODUCER-CONTRACT.md §5

  ) — default

  Skills-Results/{project}/market-research/…

  / or a folder path to match your repo (e.g.,

  docs/research/

  ). Skip = default. One file per run regardless of location (Rule 4).

What does this idea have going for it that could carry into other markets? Name your (1) core technology / unique capability, (2) the team's expertise and unfair advantages, (3) resources already in hand — money/runway, partners, traction, distribution, data, brand, and (4) any hard constraints or non-negotiables (regulatory, geographic, ethical).

AskUserQuestion

• Local vs global — is the market local (one country/city, local channels, local competitors) or global? Deep mode: which local sources, marketplaces, or competitor names does the user already know? (The built-in web search often misses local-market players — user-named local sources are the workaround.)
• Segment specifics — anything the user already knows about who buys and why (from sales, support, interviews), even fragmentary.
• Sizing logic — when the market has no ready-made reports, agree the calculation logic with the user before computing: what is the licensable/billable unit (seats, screens, locations, transactions), what real-world object it attaches to, and what extrapolation path makes sense (e.g., software licensed per screen → screens per location → locations per vertical). Propose a logic; let the user correct it.
• What NOT to do — directions, segments, or framings the user has already ruled out.

• User claims and materials are hypotheses, not facts. They enter the analysis tagged, never silently merged with researched facts, and never silently baked into the wedge.
• Deep mode: load-bearing claims (anything the verdict, target-segment pick, or a pivot recommendation would rest on) get a web-verification attempt (≤2 fetches each, inside existing agent budgets). Confirmed → cite the source. Unconfirmed → keep the tag.
• No verdict, target-segment pick, wedge, or pivot recommendation may rest primarily on a single unverified user input. If it does, the report says so explicitly — "this recommendation stands on your unverified input X; validate it first" — names it as the single most expensive risk, and points the corresponding RAT row at that claim.

1. Can we add value the customer notices? Can we do the segment's main tasks with added value they actually feel versus their current way? The bigger and more perceptible the gap, the better.
2. Can we earn our target margin? Does the unit economics support the average margin we want per paying customer (price or budget, minus the cost to serve)?
3. Can we create or capture demand? Can we generate demand and reach these customers — and how big and accessible are the channels? Demand you can win lives in the count of customers who have hit a problem with their current tool and are ready to switch (their switching triggers); a big segment that's happily locked into a good-enough habit, whom you can't pry loose or reach, is not a market you can win, however big it looks.
4. Is it big enough to scale? Is there enough money in it — customers × average yearly spend on this task (their job budget) — to be worth competing for?

undefined

• Format: When {context + trigger + negative emotions before}, I want to {expected outcome} with success criteria {concrete, measurable criteria — plain text}, in order to {higher-level Job + positive emotions after}. The canon uses "in order to," not "so that."
• The

  I want to

  clause names the expected outcome (the canon's primary Job element) — not just any verb. Each infinitive verb is one Job (split multi-verb statements into the hierarchy).
• Name the level every time — Big / Core / Small / Micro Job — and remember levels are relative to our product's reach, not absolute positions.
• Core Jobs = the highest-level Jobs the product performs fully. Big Jobs = motivation context one level above (not the segmentation root). Number of Core Jobs is variable — list as many as the segment performs.
• Aha Moment = the customer experiences a Core Job performed better than the success criteria they expected. Place it as early in the Critical Chain of Jobs as possible. Positioning promises only what the chain actually delivers (over-promising manufactures a Problem).
• In questions addressed to customers, use the everyday word task, never "Job."

⚠️ Numerical disclaimer. All numerical estimates are LLM-generated hypotheses. Each metric names its assumptions and carries a runnable verification path (see appendix); in Deep mode sizing is computed via 3 methods on real sources and averaged. Validate before any investment decision.

⚠️ Hallucination disclaimer. Everything in this document is generated by an LLM and may contain hallucinations in unknown places. For decisions with expensive consequences, run a full quantitative and qualitative research pass; do not act on this document alone.

CLAUDE.md

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

[Name (URL TBD)](#)

• Three layers, escalating depth — state each conclusion once per layer, never twice at the same depth. Layer 1 = the answer (headline only). Layer 2 = the reasoning in plain English. Layer 3 = the full methodology work (tables, Job statements, selection screens). The old failure was risks appearing 3–4× at the same depth (one-pager → §4 options → §5 RAT). Now: a risk is a headline in L1, a plain sentence in L2, a full row in L3 — three depths, not three copies.
• Drill-down links are mandatory. Every Layer-1 claim that a skeptic 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

  [why narrow ▸](#l2-verdict)

  and put

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

  above the target. This is what makes the simple layers trustworthy — the reader can always click through to the derivation.
• Layer 1 = minimal jargon, plain words lead. Lead every sentence in plain product English a junior PM gets at a glance. A methodology term may appear in parentheses as a short plain gloss when it genuinely helps — but never open a sentence with a raw term, and keep jargon to a minimum. Short sentences — "explain it to a smart friend."
• Layer 2 = plain language first, term glossed. On first use, gloss a methodology term in 3–5 words in parentheses — e.g., "the Big Job (the outcome the customer is really after)". Nested or repeated parenthetical glosses are fine — clarity beats purity. Link

  references/glossary.md

  once at the top of Layer 2.
• No internal methodology citations in Layers 1–2. Never write "per 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 collapsed methodology trace at the end of a subsection, styled out of the reading flow, e.g.:

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

  segmentation.md

  , Rule 18); levels named product-relative (Rules 8, 20).</sub> Never break a sentence of report prose with

  (b2b.md §7)

  . Project-internal rule numbers (

  CLAUDE.md Rule 7

  ) never appear in any layer — they are for your reasoning, not the reader.

• Disclaimers once. The two-part disclaimer appears once (top of file), plus a one-line pointer in Layer 1. Do not repeat the full disclaimer block inside Layer 3. (Search the file before shipping — the disclaimer wording should hit at most twice.)
• Keep source links for external facts (Rule 2).

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

• Unique, resolving anchors. Every

  ▸

  drill-down link points to its own unique

  <a id="…">

  that exists exactly once in the file; no two links share a target. (The live failure was two Layer-1 links pointing at the same anchor.) Before shipping, list every

  ▸

  target and confirm each resolves.
• Inline-gloss opaque Layer-3 table headers. A non-obvious column header carries a 3–6-word plain gloss right there — "Job budget (what one customer spends a year on this)," "Ready to switch (how many have hit a problem and would move)," "Reachability (how easily you can get in front of them)." Don't rely on the glossary file — a casual reader never opens it.
• Segment depth across layers (see Layer 2 / Layer 3 templates). The target segment is partially described in Layer 2 (who they are, what they're trying to get done, what they care about most, why they'll switch) with a brief strategic recommendation; the other top candidate segments get a light touch in Layer 2; the full Map of Segments at depth lives in Layer 3.
• Validation plan across layers (see templates). Layer 1 touches it (the make-or-break risk + the next action). Layer 2 carries the focused list — every risky assumption paired with how we'd check it. Layer 3 carries the detailed step-by-step validation plan per assumption, grounded in the canon (RAT).

• Layer 1 — The Answer (~1 page, zero methodology words): the verdict and the few things that matter, in plain product English, each linking down to its reasoning. Forwardable to a co-founder who's never heard of the methodology.
• Layer 2 — The Reasoning (2–4 pages, plain English, terms glossed once): how we got here for each Layer-1 claim. Where trust is built; each claim links down to the full work.
• Layer 3 — The Full Work (the detailed report + appendix): the complete methodology — Map of Segments at depth, selection screens, competitor tables, action-RAT, pivot table, sizing appendix. For readers who want the audit trail.

• Level 1 — The Answer (1 page, plain words): the verdict, who to sell to first, why, the make-or-break risk, what to do next, how big. This is the complete answer — most readers stop here. jump ▸
• Level 2 — The Reasoning (optional, plain English): how we reached each answer — the buyer in more detail, where we win, and every assumption with how to check it. jump ▸
• Level 3 — The Full Work (optional, the audit trail): the full market sizing with a do-it-yourself re-check, all segments at depth, competitors, the strategy, and the step-by-step plan to test each assumption. jump ▸

undefined

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

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

PRODUCER-CONTRACT.md §4

).</sub>

Sizing tables + verification are in the Appendix; the market-level Big Job is validated internally (in-context), not shown here.

**Sizing honesty rule.** In **Quick mode** (no internet) compute each figure **once**, bottom-up, with the calculation logic agreed in the intake (STAGE 1 Step 5), every assumption named, and the figure marked as an *estimate without data — verify via the appendix path*. Do NOT fake rigor by "averaging 3 methods" that all come from the same reasoning. The **3-method averaging (top-down / bottom-up / analog)** runs only in **Deep mode**, where each method stands on real, linked sources.

{I propose we focus on this segment because… / I'd hold off on this segment for now because… / This isn't our segment because…} {1–2 sentences — how the selection screen's four answers compose, how many are ready to switch, the binding constraint}. Coverage: ~{X}% of total market customers.

• {Causal criterion 1} — cause: {1 line on how this produces buying behaviour / value / margin / acquisition}.
• {Causal criterion 2} — cause: {1 line}.
• {Causal criterion 3} — cause: {1 line}.

1. When {context + trigger + negative emotions}, I want to {expected outcome} with success criteria {measurable, plain text}, in order to {Big Job + positive emotions}.
2. …

Sizing method + verification are in the Appendix.

For {segment with real criteria}, who performs the Core Job {Core Job} in pursuit of the Big Job {Big Job}, {Product} delivers {value through the chosen mechanic} — so that {Big Job} is achieved {how exactly: faster / more reliably / without doing X / turnkey / with guarantee}.

ajtbd-key-theses.md §22–§23

value-creation-mechanics.md

What to build to deliver this — features, delivery format, cost, the Aha Moment — is

/nmt-craft-value-proposition

's job. It generates and filters the concrete ways to deliver this value across the whole mechanics catalog; don't anchor on a feature list invented here. This report stops at the underserved criteria (where you can win) + the mechanic direction.

1. Rerun this skill on {alternative Big-Job market} — {why}.
2. Rerun with {a narrower segment / different business model / different channel} — {why}.

undefined

1. {Step 1} — {the cheapest, highest-leverage falsification first}.
2. {Step 2} — {…}.
3. {Step 3} — {…}. {Order by

   (P(wrong) × cost-if-wrong) / cost-to-validate

   . Segment-and-Jobs validation usually comes first.}

• Method (per canon): {the right test for this kind of risk — e.g., AJTBD customer interviews on past behavior for a Segment-and-Jobs risk; a fake-door / landing-page smoke test or a priced letter-of-intent for a willingness-to-pay risk; a concierge / done-manually run for a value-delivery risk; a back-test against historical data for a prediction risk. Name why this method fits — RAT: test the riskiest, cheapest-to-falsify first; interview about real past Jobs, not hypotheticals.}
• Steps: {numbered, concrete — who to recruit and how many, what to ask or build, what to measure. Use task, never "Job", in any question put to a customer.}
• Kill criterion: {the specific result that falsifies the assumption — "if fewer than X of N behave this way, the assumption is dead and we {narrow / pivot / stop}." State the threshold up front so the test can't be rationalized away.}
• Cost / time: {the honest cost and rough timeline — no artificial "≤1 week" cap.}

<sub>▸ methodology trace. Validate the riskiest assumption first, cheapest-to-falsify first; the goal is to kill or pivot before the build (

rat-key-theses.md

). Interview about real past tasks, not hypotheticals; recruit the people who actually performed the Job (

segmentation.md

).</sub>

undefined

**Re-check {SOM / segment size}:**
1. **Count the buyers.** Go to {named source + link}. Pull {the specific figure / filter to apply}. → you should land near {our input}.
   - *Where to look:* {pick the ones that fit the market} — official statistics ([U.S. Census / County Business Patterns](https://www.census.gov/programs-surveys/cbp.html), [Bureau of Labor Statistics](https://www.bls.gov/), [Eurostat](https://ec.europa.eu/eurostat), [data.gov](https://data.gov/)); industry analysts ([Statista](https://www.statista.com/), [IBISWorld](https://www.ibisworld.com/), Gartner/Forrester press releases); trade & industry associations for the vertical; company counts ([Crunchbase](https://www.crunchbase.com/), [LinkedIn](https://www.linkedin.com/) company/headcount filters, job-posting volume as a proxy for hiring/scale); public financials ([SEC EDGAR 10-Ks](https://www.sec.gov/edgar/searchedgar/companysearch), annual reports).
2. **Get the price.** {How to find what one buyer pays — competitor pricing pages, [G2](https://www.g2.com/) / [Capterra](https://www.capterra.com/) plan tiers, procurement records, the user's own quotes}. → compare to {our annual price}.
3. **Bound the win-rate (SOM only).** SOM is not the whole market — it is what you can realistically win in 1–2 years through the channels you actually have. Estimate it as {reachable-via-your-channels} × {a conversion benchmark for your motion — e.g., outbound/PLG/sales benchmarks from [OpenView](https://openviewpartners.com/), [First Round](https://review.firstround.com/), public SaaS benchmarks}. → compare to {our win-rate}.
4. **Redo the multiply** (step 1 × step 2 × step 3). **Confirm/break rule:** within ~30% of our number confirms the order of magnitude; off by >2× means an input is wrong — the table above shows which one to challenge first (the one tagged the weakest).

Keep this section concrete and linked. A reader should be able to open the sources, redo the arithmetic in 20 minutes, and either trust our number or find exactly which input to push on. Full input breakdowns and divergence notes stay in-context, not dumped into the file.

1. Segments = similar Core Jobs + similar success criteria — not demographics, not Big Jobs, not industry.
2. Real criteria are causes (a behaviour / characteristic explaining how we create value, earn margin, or acquire), not paraphrased value or consequences.
3. Selection screen applied to every segment, and the focus pick justified on it.
4. Switchability assessed — the segment has triggered, unsatisfied customers willing to switch (the Problem is the trigger), not only habitual locked-in users.
5. Jobs use the canon grammar —

   When … I want to {expected outcome} with success criteria … in order to …

   ; one expected outcome per Job; levels named and product-relative.
6. Core vs Big distinguished — Core = highest Jobs the product performs fully; Big = motivation above, not the segmentation root.
7. Aha Moment placed — where delivered value beats the customer's expected criteria; positioning promises only what the chain delivers.
8. Competitors defined by Jobs, not categories — direct on the Core Job; indirect on the Big Job, incl. do-nothing and non-obvious substitutes.
9. Wedge = an underserved success-criterion intersection + a one-line published-mechanic direction — no feature list (features are

   /nmt-craft-value-proposition

   's job).
10. RAT walks the cause-and-effect chain, each risk positive + falsifiable + paired with a validation action; riskiest-and-cheapest-to-falsify ordered first.
11. Pivot markets evaluated on the same selection screen against the extracted assets; existential-risk gate applied; each is a concrete Segment + Big-Job pair.
12. User claims stayed hypotheses — every load-bearing user claim is tagged (data / observation / hunch); no verdict, target-segment pick, or strategy rests primarily on a single unverified user hunch without saying so; "I don't have this info" answers surface as explicit assumptions, not invented specifics.
13. Strategic options are ranked hypotheses — 3–5 options, each with a mechanism, a main risk, and a first cheapest validation step; none reads as consultant advice to follow blind.

• Plain-language-led — every user-facing point leads in the reader's own words; methodology terms only in parentheses (never jargon-first); the methodology appendix / debug may stay in full terms.
• Three layers present and correctly leveled — Layer 1 (minimal jargon, plain words lead, terms only in parentheses), Layer 2 (plain reasoning, terms glossed), Layer 3 (the full work). No conclusion is repeated at the same depth across layers.
• Drill-down links resolve and are unique — every Layer-1 claim links to a real Layer-2 anchor; every Layer-2 claim links to a real Layer-3 anchor; every

  #l...

  /

  #disclaimers

  target exists exactly once and no two links share a target.
• Segment depth across layers — the target segment is partially profiled in Layer 2 (who · what they're getting done · what they care about · why they'd switch) + a brief strategic recommendation; other top segments touched in Layer 2; the full Map of Segments at depth is in Layer 3.
• Validation plan across layers — Layer 1 touches it; Layer 2 lists every risky assumption paired with how we'd check it; Layer 3 gives the detailed step-by-step plan per assumption (Method / Steps / Kill criterion / Cost), canon-grounded.
• Opaque Layer-3 table headers carry an inline plain gloss (Job budget, ready to switch, reachability, etc.) — and never use the non-canon term "switchable demand" in any rendered header or row.
• Disclaimers once — full two-part disclaimer at top only; Layer 1 has the one-line pointer; Section 6 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.
• Step ledger ran — every pipeline stage checked off by name; any skip was declared, never silent.
• Producer contract satisfied (

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

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

  .html

  with resolving anchors +

  <details>

  ; the "What you told me — and the risks I see in it" block present (unless no input given); validation-debt line in Layer 1; every

  GO

  written as

  GO (to validation)

  ; Deep mode hit its evidence floor + self-critic loop (or flagged thin coverage + offered the web MCP).

1. Hold the user's input in context (no

   00-input.md

   file) — including the materials read from the user's paths, the clarifying answers, the claims ledger, and the confirmed direction (STAGE 1 Steps 5–7).
2. Read the eager core (

   ajtbd-key-theses.md

   +

   segmentation.md

   ). Pull each staged file (

   rat-key-theses.md

   ,

   nmt-key-theses.md

   ,

   value-creation-mechanics.md

   ) the first time the run reaches the stage that uses it — not before (see "Methodology — source of truth").
3. Build the Layer-3 work first, directly from reasoning: market snapshot → Map of Segments (all segments, selection screen) → differentiation → pivot (extract assets from the input, generate 3–5 alternative Big-Job markets with segment+Jobs hypotheses, score them on the selection screen) → strategic options (top 3–5, ranked) → action-first RAT → appendix. Add the section anchors.
4. Run the self-critic criteria over the draft; fix in place; keep the methodology trace fenced (Layer 3) or in-context.
5. Step ledger: before writing the file, check every pipeline stage above off by name. A skipped stage is never silent — say which stage was skipped and why, and get the user's OK if it affects the verdict.
6. Compute Layer 2 (the reasoning) and then Layer 1 (the answer) LAST, from the finished Layer-3 analysis — so the simple layers summarize the real work, with drill-down links wired to the Layer-3 anchors.
7. Write the single result file (top disclaimers once → Layer 1 → Layer 2 → Layer 3).
8. In the chat: print the brief outcome + Layer 1 + rerun suggestions + the file path (see "End-of-run chat output").

• Writes one file

  Skills-Results/{product-slug}/market-research/{YYYY-MM-DD_HH-MM}_{product-slug}-market-research-result.md

  ; new file per run.
• Agents are spawned with the

  Agent

  tool,

  subagent_type: "general-purpose"

  ,

  run_in_background: true

  . Within a wave, independent agents run in parallel; the orchestrator waits for a wave to finish before the next.
• Each agent reads only the canon slice its wave needs (per "Methodology — source of truth": sizing & competitor agents → eager core only; Strategy → core + rat + nmt + mechanics; Pivot → core + nmt) and returns its result in its final message — no per-agent files. The orchestrator holds those returns in context. No live-tail /

  Monitor

  machinery.
• Web caps (hold the longest legs): reviews-mining ≤ 12

  WebFetch

  / ~10 min; synthesis ≤ 6; strategy ≤ 4. Pivot agents are reasoning-bound (≤ 2 fetches if any).
• Evidence floor, not just a ceiling (

  PRODUCER-CONTRACT.md §6

  ). Each web leg also has a minimum: it may not return "done" until it has hit a real floor of distinct sources for its task (sizing → ≥3 independent inputs; competitors/reviews → ≥4 competitors with real review sources) or explicitly reported why fewer were possible (blocked / none exist). "Did two queries and stopped" is a failure, not a completion.
• Self-critic loop per leg. After a leg returns, a critic pass checks: enough distinct sources? load-bearing claims verified against a real source? any methodology error (segment by demographics, Big-Job-as-segment, features-before-criteria, undersized SAM)? gaps? If it fails, re-run the leg with the gap named — up to 2 extra rounds. Don't ship a leg that failed its own critic (this is the fix for "promised deep research, did two fetches, quit").
• Web-MCP fallback. When the built-in fetch is blocked or thin on a needed source (G2, Capterra, local-market sites), tell the user once and use a web-research MCP if one is connected — Firecrawl or Exa (both ship MCP servers; discover via tool search). Without it, proceed and flag thin coverage in the verification checklist.
• Source links mandatory (Rule 2); never invent sources or figures.

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

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

+

…/segmentation.md

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

1-

prefix on the canon folder.) Keep methodology citations and canon paths out of report prose — hold them in context (the orchestrator fences any that belong in Layer 3). Every named external source is a clickable Markdown link. Return your full result in your final message — do not write any files.

ajtbd-key-theses.md

segmentation.md

nmt-key-theses.md

value-creation-mechanics.md

1. Hold the user's input in context; record start time.
2. Spawn Wave 1 (1A, 1B, P1→P2) in background; wait for all; collect their returns.
3. Spawn Wave 2 (Segments) with the Wave-1 returns; wait.
4. Spawn Wave 3 (Strategy + P3) in parallel; wait.
5. Assemble the single file as the three layers: top disclaimers (once) → How to read this (3 levels, with jump links) → Layer 1 (The Answer) → Layer 2 (The Reasoning) → Layer 3 = Section 1 (sizing) → Section 2 (segments) → Section 3 (differentiation) → Section 4 (within-segment switches + alternative markets + strategic options) → Section 5 (action-RAT) → Section 6 → Appendix. Add the section anchors; compute Layer 2 then Layer 1 LAST from the assembled Layer-3 work, wiring drill-down links to the anchors; fence any methodology citations into

   ▸ methodology trace

   lines.
6. Step ledger: check every wave and every section off by name before assembly; a skipped stage is declared to the user, never silent.
7. Source-link audit; flag any bare or "URL TBD" sources in the checklist.
8. Chat output (below).

1. Brief outcome — 3–5 lines: the verdict, the focus pick, the top risk, and whether a pivot market looks more promising than the original idea.
2. Layer 1 (The Answer), printed verbatim.
3. Concrete rerun suggestions — e.g., "Re-run for the Big-Job market

   {X}

   where your

   {asset}

   also applies, or with a

   {per-worker / subscription}

   model for

   {segment}

   ?"
4. Path — the single result file.

• No quantitative survey (300–500 respondents), no ABCDX analysis of existing customers, no full unit-economics model — those are separate skills.
• Quick mode: no internet, no subagents, no quantitative validation.
• Does not pause to ask the user mid-pipeline (Deep mode runs straight through).
• Does not invent sources or numbers; thin data is recorded as thin, never fabricated.

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-market-research${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.