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) — ../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 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. 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).
   • 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 primary 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 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 primary 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: 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); I want to + verb is the primary element of an eight-element Job (each verb a separate Job); 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).

Shared output guardrails: every named external source is a clickable Markdown link; include the two-part disclaimer at the top of the result; use US-context analogs + the recognition test — only Tier A/B brands without a one-clause bridge.

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.

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

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

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

One batched structured-input request

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):

• Target segment + causal criteria (behaviour/characteristic, not demographics).
• 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.
• 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.
• Direction confirmation. Before S1, play the understanding back in one short block — "Here's what I understood: {segment, the value we're communicating, validation status + what's still unvalidated from the hand-off, which assets you need}" — and confirm via one structured-input request (Confirm / Correct).

S1 — Write the GTM communication pack

Build Layer 3 (the full pack) first, in the order below — each part references the same Job record, so the one-liner and the Big Job stay consistent across all assets. Then compute Layer 2 (the plan + why), then Layer 1 (the GTM in one breath), LAST from the finished pack, wiring the drill-down links to the Layer-3 anchors. Write the file in final order: top disclaimers (once) → glossary link → How to read this (3 levels, with jump links) → Layer 1 → Layer 2 → Layer 3. Quick mode does this in one pass; Deep mode parallelizes the Layer-3 parts (below).

The file opens with the disclaimers once, then the glossary link:

# Go-To-Market Communication — {product / segment}

<a id="disclaimers"></a>
> **Numerical disclaimer.** All numerical estimates are LLM-generated hypotheses with verification paths. Validate before deciding.
> **Hallucination disclaimer.** Generated by an LLM; may contain hallucinations. For expensive decisions, run real research; do not act on this alone.

*Methodology terms are defined in the [glossary](references/glossary.md).*

How to read this — the three levels

Emitted once, right after the disclaimers/glossary and before Layer 1, so the reader sees the structure and can jump. Plain words only:

## How to read this
Three levels — go as deep as you need:
- **Level 1 — The GTM in one breath** (1 page, plain words): the one-liner, the single message, who it's for, the first channel to try, the one thing to test before scaling. Most readers stop here. [jump ▸](#layer-1)
- **Level 2 — The Plan & why it's shaped this way** (plain English): why this is the message, the landing logic, the ad angles, the channel plan, what to test first. [jump ▸](#layer-2)
- **Level 3 — The Full Pack** (ready-to-ship): all the landing & ad copy, the channel plan, the deal room, and the consideration map. [jump ▸](#layer-3)

Layer 1 — The GTM in one breath

Computed LAST, from the finished Layer-3 pack. Minimal jargon, plain words lead, forwardable (a term may appear in parentheses as a plain gloss, but never opens a line). Each doubtable line drills down to its own unique Layer-2 anchor — never two lines at the same target.

---

<a id="layer-1"></a>
# The GTM in one breath
*One page, plain words — forward this to a co-founder. The full plan and the ready-to-ship copy are below.* — [disclaimer ▸](#disclaimers)

## The one-liner
{the single sentence used everywhere — what it is + what it does + the value in plain words.}

## The one message everything routes through
{in one or two plain sentences: the single thing the buyer must come to believe; every asset carries it.} [why this is the message ▸](#l2-message)

## Who it's for
{the segment in one plain sentence — who they are, not a methodology label.} [the buyer + the validation status ▸](#l2-buyer)

## The channel to try first
{one channel + the moment to catch them, in plain words.} [the channel plan ▸](#l2-channels)

## The one thing to test before scaling
{the single make-or-break thing to prove first — usually whether the value is real, or whether the top channel actually reaches them.} [what to test first ▸](#l2-test)

> **Validation debt:** this pack stands on **{N}** unvalidated assumptions — **{M}** of them fatal (would sink it if wrong): that the value is real, that this message lands, and that the top channel reaches them. The fatal ones are the first things to test. [see them ▸](#l2-input-risks)
> <sub>N = the assumptions the copy rests on (the value claim, the message, each channel + lead-magnet hypothesis, plus anything inherited unvalidated from the upstream artifact); M = those that kill it if wrong. A quick draft on an unproven value claim carries a lot of debt — and this says so honestly.</sub>

> ⚠️ {validation flag — ≤2 lines, placed here below the answer, not above it. This pack has no GO/build verdict: it always reads as **"test this messaging / channel,"** never **"this will work."** "value validated by sales/usage" → these are scale-ready creatives; "value is a hypothesis" (incl. inherited from an unvalidated upstream value prop) → these are demand-test creatives, not facts to scale. Path D → reduced-confidence flag; else name the source artifact and what of its debt is still open.}

Layer 2 — The Plan & why it's shaped this way

Computed after Layer 3, before Layer 1. Plain English, one gloss per methodology term, no big copy blocks (those live in Layer 3). Each subsection carries the <a id> anchor Layer 1 links to, and links down to its Layer-3 part.

---

<a id="layer-2"></a>
# The plan, and why it's shaped this way
*Plain-English reasoning behind the copy. The ready-to-ship assets are in the full pack below.*

<a id="l2-input-risks"></a>
## What you told me — and the risks I see in it
*Everything you gave me — the upstream value prop / PRD / research, your deck, your landing, your numbers — I treated as a hypothesis, not as fact. These are the inputs the copy leans on, and what I'd check before trusting each. Copy is the most public thing you ship — over-promising on an unproven claim creates disappointment at scale.* (Omit this block only if the user provided no claims or materials at all.)

| What you provided / claimed | How I treated it | The risk I see in it | How to check it fast |
|---|---|---|---|
| {claim or material, tagged data / observation / hunch} | {used as hypothesis in {where — the message / a copy claim / a channel}} | {the specific risk — e.g., "this is your stated value, not customer-validated; the real Job may differ, and the headline rests on it"} | {the cheapest falsifying test} |

{If the message, a headline claim, or the validation flag rests primarily on an unvalidated input, say so here in one bold sentence and tie it to the matching `[VERIFY — source]` tag in the copy.}

<a id="l2-message"></a>
## Why this is the message
{what the buyer must come to believe before they switch, in plain words — the better outcome they're really after (the Big Job), and the few things they must learn or believe to switch (the Consideration Activators) for the message to land. Why we lead on this and not on features.} [what each asset is doing ▸](#l3-camap)

<a id="l2-buyer"></a>
## Who it's for — and whether the value is proven yet
{the segment in plain words; whether the value is validated by sales/usage or still a hypothesis (which decides scale-the-copy vs. demand-test-the-copy).}

## The landing logic, in plain terms
{why the page is ordered the way it is — recognize the situation → show the value in concrete terms → prove it → handle the fears → the first small step — in plain words.} [the full landing copy ▸](#l3-landing)

## The ad angles to test
{the handful of angles worth testing first and why, plain.} [all seven ad angles + variants ▸](#l3-ads)

<a id="l2-channels"></a>
## The channel plan
{the top channels, the moment to reach the buyer, and the lead-magnet / content / referral moves, in plain words.} [the full channel plan + deal room ▸](#l3-channels)

<a id="l2-test"></a>
## What to test first
{the single cheapest highest-leverage thing to prove before spending on scale.}

Layer 3 — The Full Pack

The deliverable in substance. Open it with a divider and the heading, then the one-liner part, then Parts 1–3 and the Appendix. All canon citations are fenced into ▸ methodology trace lines at the end of each part — never inline in copy or prose.

---

<a id="layer-3"></a>
# The full pack

## 0. The one-liner (used everywhere)
**`[What it is] + [Core Job(s) it performs] + [value by criteria]`** — one sentence, plain words already in the customer's head.
Examples of the form (not to copy): *Bench — bookkeeping service that categorizes transactions and delivers tax-ready financials for small businesses.* Test: a stranger can repeat what it is, the Core Job, and the value.

Part 1 — Landing copy (full, read

…(truncated)