Nmt Craft Go To Market

Craft Go-To-Market (GTM communication) v1 — 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.

One breath. This skill turns the value you've already built into the copy that brings in customers — landing copy, ad/creative copy, and a launch + growth plan. It's the last step of the chain and builds on the steps before it; it never invents the segment, the value, or the build. Everything is said through the bigger outcome the customer is really after (their Big Job, where motivation lives), in concrete, measurable terms (success criteria, not adjectives), with features used as proof, not as the message. Copy can carry value, not manufacture it: if the value isn't proven yet, the skill says so up front — it can still write you demand-test copy, just don't scale on it.

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 frame the pack as test this messaging, never this will work (GTM has no GO verdict — it inherits the debt of the value it sells); (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.

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)      (the build spec)         (THIS SKILL: the copy
                                                                          that sells the value)

It runs from a plain-English description of your product, your customer, and what you sell — that's a first-class way in, not a fallback. If you've already run an upstream skill, even better: it'll use a $nmt-craft-value-proposition result (best — it carries the positioning headline, the dominant criteria, the moment it clicks for the customer (the Aha moment), the differentiation, the proof), a $nmt-product-requirements PRD (the real functionality, the step-by-step path the customer walks (the Critical Chain of Jobs), where the Aha lands), or a $nmt-market-research result (segment, Big/Core Jobs, competitors, the underserved angle you win on). Either way, it does not re-derive segments, re-invent value, or re-spec the build — it packages what you give it into customer-facing language. (One footer point only: copy can't prove value, so test the value before you scale spend — more below.)

What this skill produces

One file — the GTM communication pack ({product-slug}-craft-go-to-market-result.md), in three reading depths, linked top-to-bottom (so one pack serves the founder skim, the marketer's "why is the copy shaped this way" read, and the methodology audit). The actual copy — landing blocks, ad lines, deal-room assets — is the product; it stays plain and shippable and is never buried or abstracted away. The layering here is lighter than the analysis skills: it adds a quick top layer and a short why-layer above the full pack, and it strips the methodology citations out of the copy itself.

1. Layer 1 — The GTM in one breath (~1 page, zero methodology words, forwardable): the one-liner · the single core message everything routes through · who it's for · the top channel to try first · the one thing to test before scaling — each doubtable line drilling down to its reasoning.
2. Layer 2 — The Plan & why it's shaped this way (1–2 pages, plain English, terms glossed once): why this is the message (what the buyer must come to believe), the landing logic in plain terms, the ad angles to test, the channel plan summary, what to test first — each linking down to the full pack.
3. Layer 3 — The Full Pack (the deliverable in substance — and only the assets you asked for: if you picked just landing + a couple of ads, that's all it writes; it doesn't dump the whole growth pack on you):
   • Part 1 — Landing copy. The full landing-page sequence, ready-to-publish copy, no placeholders.
   • Part 2 — Ad / creative copy. Seven ad angles (each a Job-language formula) with test-variant sets; a visuals brief that shows the after, the result they want (State B); the one-liner used everywhere.
   • Part 3 — GTM / growth plan. Channel ideas to try (each loaded with the few things a buyer must learn or believe to switch — the Consideration Activators); lead magnets that catch them one step earlier (the Previous Job), content and referral loops; cross-sell into the next thing they do (the Next Job), upsell toward the bigger outcome (the Big Job), and retention messaging (a stream of Aha moments, frequency, reusing habits they already have).
   • Part 4 — Claims I could not back: everything in the copy that isn't traceable to something you gave me — invented claims, single-source signals — with the cheapest way to confirm each. Always present, even when it's empty.
   • Appendix — what each asset is doing: which of the five switch-me-over pieces (the Consideration Activators) each asset carries, and which forces of behavior change it works.

Two modes:

• Quick (default, ~10–15 min): one Codex agent, no internet. Writes all copy from the loaded artifacts + reasoning.
• Deep (opt-in, longer): subagents mine real customer-review language (so the copy uses the words already in the customer's head) and ground the competitor-firing (Consideration-Activators component 5) in real Problems. 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. 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 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 sets below — the per-task algorithms (positioning, conversion, acquisition, retention, average-check) live behind the paywall, and their communication content is folded into the public files below: positioning/landing/creatives in communication.md; conversion in communication.md + customers-attention-management.md + barrier-removal.md; acquisition/cross-sell/retention in job-types-and-properties.md + critical-chain.md + consideration-activators.md. This holds in both repos — even when running inside the Internal repo where those files exist on disk.

Eager core (read before any copy is written — every run):

Staged — load only at the stage that uses it:

Quick mode (one Codex agent): read the eager core, then pull each staged file the first time the run reaches its stage — not before. Deep mode: each writer agent reads only the files its part needs (Landing → core + customers-attention-management + barrier-removal; Ads → core; GTM → core + behaviour-change + job-types-and-properties + critical-chain + b2b-if-B2B + value-creation). Never have an agent load a file outside its slice.

Path note. If a file is not found at the path above, 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.

Do NOT use generic JTBD from the internet or prior training. Five mis-defaults to never propagate (per project AGENTS.md): a Job is a desired transition (State A → expected outcome), not "a struggle for progress"; value is energy efficiency measured against the brain's prediction, the Aha Moment is value beating prediction (never PPE/NPE — Rule 22); I want to + verb is the primary element of an eight-element Job (each verb a separate Job — Rule 7); a Problem is a consequence of an underperforming Solution, not a root cause; a Solution is a real thing and a label for the Job Graph it installs.

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

• Communicate through the Big Job — motivation lives one level above the Core Job (behaviour-change.md §4, communication.md §3). Exception (Class 1, behaviour-change.md §10): when our Core Job is already familiar to the segment, lead on the Core Job + criteria with the Big Job as reinforcement; when unfamiliar (Class 2), lead on the Big Job and back-fill the Core Job.
• Value in concrete success criteria, never adjectives — "fast / reliable / high-quality" are bullshit-words; ask "as in?" → "car arrives in under 4 minutes," "insured for $30M," "e-filed with error checks." (communication.md §3.)
• Features are proof, not the message — a feature is communicable only after it's attached to a Job and a criterion (communication.md §4). Lead with the Job + value + fear reduction; use features as evidence.
• Never promise a Big Job the product only partially performs — overpromise inflates the prediction and manufactures a Problem; the promise must match what the Critical Chain of Jobs actually delivers (communication.md §9, value-creation.md §6–§7).
• Load all five Consideration-Activators components — new Job Graph; value delta by criteria; named product + entry path; specific fears reduced; competing Job Graph fired (consideration-activators.md §1).
• Communication transmits validated value — if value isn't proven (no sales / no Aha Moment yet), flag it; don't scale copy on a hypothesis (communication.md §1).
• Specific stories beat abstractions (consideration-activators.md §6); visuals show State B, not the process (communication.md §6).
• The copy belongs to the user's market, not to a default one — the channels, the price anchors, the competitors you fire at, the proof, the examples, the cultural references and the tone all come from the market and language the user named at intake. This is the invariant that breaks most often: a Kazakhstan product pulled toward Russian channels and Russian price points, a Brazilian product given US brands. Ask the market question, then obey the answer.
• Every claim in the pack carries its status — backed by a quote or data, derived from the inputs, or the model's hypothesis. Nothing invented ships inside customer-facing copy (see "Claim statuses" below).

Per AGENTS.md: every named external source is a clickable Markdown link (Rule 2); two-part disclaimer at the top of the result (Rule 3); the recognition test — only brands the audience actually knows, or bridged in one clause (Rule 19). With no market named, default to a US audience and US-context analogs (Rule 6); once a market is named, that market's analogs replace them everywhere.

Plain-language output — segment words first, methodology in parentheses

The reader of this output is a product person, not a methodologist. Write the GTM plan, rationale, and annotations 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. (The customer-facing landing / ad copy itself is of course plain by definition — this rule also keeps the explanations around it jargon-free.)

• ❌ "This banner uses the Trigger → Core Job formula and fires the competing Job Graph…"
• ✅ "This banner is the right-moment angle — it catches them right when they feel the problem, then shows why the usual option falls short (a Trigger → Core Job Job-language formula that also fires the alternative)."

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 only when it earns its place): the result they're after (the Job / Big Job) · the biggest task your product does on its own, end to end, and can't go higher right now (the Core Job) · the step-by-step path the customer walks (the Critical Chain of Jobs) · the exact step where they get stuck (a Critical Chain of Jobs break) · the moment it clicks / clearly beats what they expected (the Aha moment) · the bad surprise when a tool does a task worse than expected (a problem) · getting the result for less time, effort, money, or stress than expected (value) · the few things they must learn or believe before switching (Consideration Activators) · a real blocker vs. just a worry (a Barrier vs. a fear) · the assumption most likely to kill this, tested cheap first (the riskiest assumption / RAT). Never write "Positive / Negative Prediction Error" in anything the user reads — say "Aha moment" / "problem".

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 any explicit methodology appendix, where full methodology language is expected. The lead the reader sees is plain; the parenthetical and the appendix carry the precise terms.

Link references/glossary.md once at the top of the GTM pack, right after the disclaimers.

Claim statuses, honest confidence, and where invented ideas go

Every claim in the pack carries one of three statuses — and says which one it is.

• Backed — a quote, a number, or a document stands behind it. Cite it; for review evidence say how many said it and link them ("9 of 27 reviews of {competitor}: [links]").
• Derived — you worked it out from the inputs. Say from what.
• My hypothesis — your own guess: an ad angle, a channel, a lead magnet, a claimed benefit. Say so plainly.

Three hard rules on top:

• A number a person said is that person's opinion, not a market fact. "60–70% of deals go through tenders" is written "per the sales lead — his estimate, not a measured figure" and never becomes a landing-page claim. Same for "our customers always…" from a founder or a deck.
• Nothing you invented ships inside customer-facing copy as fact. Ad angles and channel ideas are supposed to be hypotheses — that's fine, they get tested. Product claims are not. A guarantee, a warranty, a refund policy, a feature, an integration, a certification, a number: if it isn't in what the user gave you, it does not go in the landing or the ad. It goes into "Claims I could not back — do not ship until checked" in the full pack, with the cheapest way to confirm it. (This failure is real: an invented product-lifetime warranty travelled into a value proposition as if customers had asked for it — copy is where that mistake becomes public.) Anything the user asked to keep but that isn't verified ships with its [VERIFY — source] tag intact.
• Confidence scales to what the user actually gave you (dynamic honesty). No upstream artifact, no interviews, no reviews — just a description — means the run is thin, and the pack says so right under the Layer-1 answer: "⚠️ Thin input: this ran on your description alone. Treat the copy as demand-test material and the channels as guesses." On thin input give ranges rather than point numbers (budgets, conversion expectations, timelines), and end Layer 2 with the top 3 inputs that would raise accuracy most (e.g. "reviews of {the top local alternative}," "10 sales-call recordings," "your current landing's conversion by source"). Computed per run — the fixed disclaimers at the top don't cover it.

Readability rules (the pack is for a marketer who doesn't live in the methodology)

The pack is three reading depths in one file, linked top-to-bottom like canon §-references. The founder skims Layer 1; the marketer reads Layer 2 to understand why the copy is shaped this way; the methodology audit lives in Layer 3. The full template is in "GTM pack 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 = the GTM in one breath (headline only). Layer 2 = the plan + why it's shaped this way, in plain English. Layer 3 = the full pack (all the copy, the seven-formula tables, the channel plan, the deal room, the CA map). A point made in Layer 1 is a headline; in Layer 2 a plain sentence; in Layer 3 the full asset — three depths, not three copies.
• Drill-down links are mandatory. Every Layer-1 line a reader could doubt carries a ▸ link to its Layer-2 anchor; every Layer-2 claim links to the Layer-3 part that delivers it. Use Markdown anchors: write [why this message ▸](#l2-message) and put <a id="l2-message"></a> above the target; the Layer-3 copy parts carry <a id="l3-landing"></a>, <a id="l3-ads"></a>, <a id="l3-channels"></a>, <a id="l3-dealroom"></a> above them.
• 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.
• 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. The glossary is linked once at the top of the pack. Glossable terms include the sneaky ones — State A/B, Previous/Next/Orientation/Viral Job — gloss each once or don't use it.
• The landing and ad copy in Layer 3 is already plain by definition — keep it clean and shippable. Do not abstract it, do not gloss it, do not wrap it in methodology. The copy is the deliverable. But every claim/number in shippable copy keeps its [VERIFY — source] guardrail until it is proven — a reader copies the copy straight to production, and the top-of-file disclaimer won't stop them from shipping an unproven number.
• Citation fencing — the big fix for this skill. Strip every inline canon citation — (communication.md §8), (b2b.md §1), (consideration-activators.md §1), (behaviour-change.md §…), etc. — out of the copy and out of all surrounding prose. The landing blocks and ad lines must read as clean, shippable copy with no methodology citations inside them. Where the canon reference still matters to the marketer reading the pack, move it into a fenced methodology trace line at the end of a part, styled out of the reading flow, e.g.:

  ▸ methodology trace. The landing block sequence is a short Critical Chain of Jobs whose State B is enough belief to take the first step (communication.md §8); the fear-reduction and competitor-firing blocks load Consideration-Activators components 4–5 (consideration-activators.md §1, barrier-removal.md §3). Never break a line of copy or a sentence of pack prose with (communication.md §8). Project-internal rule numbers (AGENTS.md Rule N) never appear in any layer — they are for your reasoning, not the reader.

• Disclaimers once, and the answer comes first. The two-part disclaimer appears once at the top of the file. The validation flag sits below the Layer-1 answer, capped at 2 lines — a wall of "this isn't proven yet" before the answer makes a reader think the product is broken and bail; let them read the answer first, the caveat second. A one-line pointer in Layer 1 is enough; do not repeat the block inside Layer 3. (Search the file before shipping — disclaimer wording should hit at most twice.)
• Keep source links for external facts and proof (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.
• [VERIFY] survives into the copy. Every number/claim in landing and ad copy carries its inline [VERIFY — source] tag until proven — do not strip it because the copy "reads cleaner" without it. The earlier run dropped these and a reader would ship unproven numbers.
• Validation flag below the answer, ≤2 lines (see Disclaimers rule above).
• Zero-knowledge readability, and tooltips in HTML. Every line of the pack — copy, plan, and annotations — has to make sense to someone who has never heard of this methodology; explain it the way you'd explain it to a smart 8-year-old, in everyday words. No abbreviation ships unexplained, including ones you coin. In an HTML run, wrap every abbreviation and methodology term on first use in <abbr title="plain explanation"> — CTA, CAC, LTV, A/B, UTM, Big Job, Core Job, Aha moment, Consideration Activators, State B, Previous / Next Job — with the tooltip itself in everyday words, never more jargon. The shippable landing and ad copy stays untouched: no tooltips inside the copy blocks.

Output file (one file per run — AGENTS.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}/craft-go-to-market/{YYYY-MM-DD_HH-MM}_{product-slug}-craft-go-to-market-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, <abbr title="…"> tooltips on the first use of every abbreviation and methodology term outside the copy blocks, source links opening in a new tab). HTML carries the identical content — same attribution, disclaimers, three layers, all copy, tables, links — just in a more readable shell; the landing/ad copy stays plain and shippable, with its [VERIFY — source] tags intact. Never write both; one file per run.
• If the user gave a custom path, write the one file there with the same filename pattern.
• Everything internal — the normalized input (source artifacts, segment, Big/Core Jobs + criteria, Aha, competitors, proof, fears), dropped variants, review-mining notes, 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 GTM pack opens with the attribution top-line (the very first content, above the disclaimers) and closes with the attribution block — utm_source=nmt-craft-go-to-market&utm_medium=skill-artifact.

S0 — Intake & route

Orientation (helicopter view) — print before the first question (PRODUCER-CONTRACT.md §1)

Before any question, print this short orientation block in plain words, in the user's chosen language:

What you'll get: one pack — ready-to-publish landing-page copy, ad/creative copy, and a GTM/growth plan (channels, lead magnets, viral loops, cross-sell / upsell / retention messaging). The steps: (1) a few questions + I read your upstream artifact → (2) I write the landing copy → (3) I write the ad/creative copy → (4) I build the channel & growth plan → (5) you get one pack in three reading depths. Where I work vs. where you decide: I write the copy and the channel hypotheses. You pick what to ship and run the field validation — A/B tests, real spend, real conversions. I can't prove a channel or a message works; I can only tell you what to test first. Two modes: Quick (default — no internet, ~10–15 min, reasoning only; good for a first draft) · Deep (opt-in — subagents mine real customer-review language + ground the competitor-firing in real Problems, longer; best on a top model with a web-research MCP). Honest caveat: this packages value into copy — it doesn't prove the value, the message, or the channel. Better copy on an unvalidated value claim only accelerates disappointment. Everything here is a hypothesis until you test it.

If you can't ask questions — announce the defaults and go

Codex often runs where interactive input isn't available. Never stall waiting for an answer. If request_user_input doesn't work or the run is non-interactive, choose defaults, state them in one line at the top of your answer, and proceed:

Running with defaults: Quick mode · intake depth: just the essentials · assets: all three (landing, ads, GTM plan) · market: {the market your text points at — otherwise US, and I say so} · output: Markdown · saved to Skills-Results/{product}/craft-go-to-market/…. Rerun with parameters in the prompt to change any of it — e.g. $nmt-craft-go-to-market deep, market Kazakhstan, landing only, output HTML.

The market guess is the dangerous one here — it decides channels, price anchors, competitors and tone. State the assumed market and audience language in the header of the pack and in the "What you told me — and the risks I see in it" block, so a wrong guess is caught before anyone ships the copy.

Intake depth — ask this first (how many questions, separate from Quick/Deep mode)

Before anything else, ask how deeply to interview the user. This sets the number of intake questions; it is independent of the Quick/Deep research mode (which controls internet + subagents). Use request_user_input (or plain chat). Print verbatim:

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 market-and-audience-language question (never skipped, at any depth), the input-route question, which assets you need, and the one or two missing facts that block the copy (who it's for · what they get · what they use today and why it's not enough). Infer or defer the rest; flag any inferred input at the top of the result. On The full interview: run the full intake below (claims ledger, hand-off debt, materials, the full normalize step).

Language

Default English. If the user writes in another language, offer to work in it. Hold the choice in context. The copy uses the chosen language; canon files and source URLs stay as-is.

Market & audience — the most important question in this skill, asked every run

GTM is where getting the market wrong costs the most: channels, price anchors, proof, tone and competitors are all local. Ask before writing a single line of copy: "Which market or region are you selling into, and what language do the people you're selling to speak?" Never infer it from the product name, from the language the user writes to you in, or from the fact that most examples you know are American.

Then obey the answer everywhere:

• Channels come from that market — the ad platforms, marketplaces, messengers, communities, review sites and press that people there actually use. Not the US default list, and not the Russian one because the user writes in Russian. Kazakhstan is not Russia.
• Price anchors, currency, units, payment habits come from that market.
• The competitors you fire at are the ones this segment really considers there — including local players you may need to look up (Deep mode) or ask about (Quick mode).
• Tone, formality, humour, proof types (regulator badges, local logos, local press) match that audience. The landing reads as written by someone in that market, not translated into it.
• If you know the market thinly, say so in one line and mark the channel table's local entries as "needs a local check" rather than inventing plausible-sounding local channels.

Note the market and audience language at the top of the result so nobody ships copy aimed at the wrong country.

One batched request_user_input

Q0 "Which market/region are you selling into, and what language does that audience speak?"  → free text; drives channels, price anchors, competitors, tone
Q1 "What's your input? (all four work — describing it yourself is a fine starting point)"
  - "I'll describe my product + customer in plain English"  → Path D (standalone — first-class)
  - "A $nmt-craft-value-proposition result"   → Path A (richest input if you have it)
  - "A $nmt-product-requirements PRD"          → Path B
  - "A $nmt-market-research result"            → Path C
Q2 "Mode?"
  - "Quick (default — fast, no internet)"
  - "Deep (subagents + web: real review language + competitor firing)"
Q3 (Paths A/B/C) "Path to the result/PRD file?"  → free text; Read it.
Q4 "Which GTM assets do you need?" (multi-select)
  - "Landing copy"  /  "Ad & creative copy"  /  "GTM / growth-communication plan"  /  "All"
Q5 "Output format?" (PRODUCER-CONTRACT.md §2)
  - "Markdown (default — faster; opens anywhere)"
  - "HTML (a bit slower; easier to read — collapsible sections + working in-page navigation; all source and drill-down links stay clickable)"
Q6 "Where to save the result?" (PRODUCER-CONTRACT.md §5)
  - default `Skills-Results/{project}/craft-go-to-market/…`  /  or give a folder path to match your repo (e.g., `docs/research/`). One file per run regardless of location (Rule 4).

Normalize the input (held in context)

Extract (and only ask the user for what's genuinely missing):

• Market / region + the audience's language — the answer to Q0. Everything else on this list is read through it: local competitors, local channels, local price anchors, local proof.
• Target segment + causal criteria (behaviour/characteristic, not demographics). A segment is Core Jobs + success criteria + their priority order — if what you were handed is a purchase channel or an industry, say so and ask which Jobs actually differ.
• Big Job(s) + their success criteria (the motivation surface — where communication lands). Personal Big Job for B2B.
• Core Jobs + dominant success criteria (direction + level). Class 1 or Class 2? (is the Core Job familiar to this segment? — sets whether copy leads on Big Job or Core Job, behaviour-change.md §10).
• The Aha Moment (the moment the product clearly beats what the customer expected — for the "give a taste on the landing" block and the activation/retention angle).
• Competitive set — direct (Core Job), indirect (Big Job), turnkey — with what each closes poorly (the wedge, for firing).
• Current-Solution Problems & specific fears (for fear reduction + competitor firing).
• Proof — cases, guarantees, logos, comparable results (with source links — Rule 2).
• Validation status — is the value proven by sales/usage, or still a hypothesis? (Gates whether this is "scale the copy" or "demand-test the copy.")

Path D takes your plain-English description and does the methodology shaping for you internally — don't make the user write anything in formal Job grammar. Collect plainly (who it's for · what they get · what they use today and why it falls short · any proof you have), then internally validate against the invariants (split any task that bundles two verbs, turn demographics into real behavior, turn adjective "value" into measurable bars) before writing. Since this run leans on your description rather than a validated upstream artifact, note that at the top of the result — not as a warning that you shouldn't be here, just so you know what to test first.

User materials, claims ledger, hand-off debt, direction confirmation (all paths)

• Materials. Ask once: "Any files or folders with material I should use — a Notion export (markdown), past research, interview notes, existing copy, your current site?" Read what's given; tag everything taken from it [user data] in-context. Existing copy is input to rewrite, not copy to preserve — confirm before reusing any of it verbatim.
• Files already sitting in the working folder — list them and ask before opening any. Glance at the working directory for things that look like product context: a README or product docs, existing landing copy, survey exports, review dumps, analytics CSVs, sales-call notes, a pricing page. If any exist, name them and ask permission before reading a single one: "I see these files that might help: {list}. May I read them? This context is processed only by your agent locally — it is not sent anywhere." Read only the ones the user says yes to; never open files on your own initiative.
• Input-as-hypothesis gate (PRODUCER-CONTRACT.md §3). Treat every input — the upstream value-prop / PRD / research artifact, the deck, the landing, the user's free-text claims, "our customers say X" — as a hypothesis, never as established fact. A landing page is the team's belief about value, not proof customers want it. Actively hunt the risks inside it (don't just record): for each load-bearing input ask — 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 (the most expensive error)? 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. The GTM copy is the most public artifact in the chain: writing confident landing/ad copy on an unvalidated value claim manufactures a Problem at scale. No copy claim may rest on an unvalidated input without being flagged — connect each such claim to the existing [VERIFY — source] / validation-flag mechanism.
• User-claims ledger. Tag the strong factual claims in the user's input (competitor facts, "our customers say…", channel beliefs) as data / observation / hunch. Copy claims built on an unverified hunch are flagged: a concrete number or comparison in customer-facing copy must trace to data, or it ships as a to-verify placeholder — never as an invented fact.
• Hand-off debt — ask what's since been checked (PRODUCER-CONTRACT.md §4c). When consuming an upstream artifact (Paths A/B/C), ask the user what from the prior artifact's validation debt has since been validated in the field — e.g., "the value prop you're handing me lists assumptions still to test; which of those have you checked since (sales, interviews, a fake door)?" Re-tag anything still unvalidated and carry it forward: if the value proposition was never validated, the landing copy inherits that debt — say so in the validation flag. Debt travels down the chain; it is not silently dropped.
• **

…(truncated)