/00-gtm-router

name: 00-gtm-router
description: >
  Plan and run the full API-first GTM chain - the orchestrator (step 00) that turns
  an ICP description plus optional budget, volume, and urgency into the right
  discovery -> qualification -> extraction -> signals -> judgment -> email-resolution sequence, with
  per-step cost estimates and rationale, then executes it skill-by-skill after a
  go-ahead. Use whenever a request spans more than one chain step or the user asks
  which tools or skills to use, in what order, or what it will cost - e.g. "plan a
  campaign for this ICP", "build me a list end to end", "we're targeting X, what's
  the play", "what would it cost to go after Y", "new client kickoff", "run the
  whole chain" - or when they hand over an ICP or client brief and want prospects
  with verified emails out the other side. Also use when partial data exists (a
  company list without signals, contacts without emails) to pick the right entry
  point mid-chain. For a true cold start - "first campaign", "never run a
  campaign", "no CRM", nothing to analyze yet - route to run-first-campaign,
  the packaged workflow that sits above the chain. For a single named step alone
  (just scrape one site, just find one email), use that component skill directly.

GTM Router - the orchestrator (00)

Every other skill in this chain wraps a tool. This one wraps the decision: given an ICP, which chain do you run, in what order, at what depth, and what will it cost. Tool-routing ("use Firecrawl for scraping") is table stakes; this skill does methodology-routing - the shape of the ICP picks the discovery path, volume picks the extraction depth, evidence type picks the signal source, every discovered list passes the qualification gate (01-icp-qualify) before credits are spent on it, and everything funnels through judgment (05) before anyone writes an email. Two model-judgment layers bracket the paid steps: the gate decides who is worth paying to know more about, the judge decides what to say to them.

The router itself spends nothing. All credits are spent inside component skills, each of which keeps its own spend gates. The router's job is to make the spend deliberate: plan first, estimate honestly, execute only after a go-ahead, and checkpoint between steps.

Inputs

• **icp_description** (required) - who the client is targeting, in plain English.
• **icp_context** - what the client sells, to whom, and what pain it removes (2-4

sentences). 05-signal-builder cannot judge without it, so collect it during planning, not four steps in. If it's missing, ask once.

• **exclusions** (optional, ask once) - competitors, current customers,

do-not-contact domains. The gate (01-icp-qualify) enforces them for free; discovery skills also apply them as filters where supported.

• **budget_ceiling**, **target_volume**, **urgency** (optional) - shape the plan.

Missing values don't block planning: assume, label the assumption, and show the math so the user can correct it.

Start where the data runs out

Discovery is only step one if the user has nothing. Route to the first step whose input is missing:

| User already has | Enter the chain at | |---|---| | Nothing yet - no list, no CRM, first campaign ever | run-first-campaign - the packaged cold-start workflow (context -> source of record -> gate -> rank -> drafts -> sheet, owner approval between steps) | | Nothing but an ICP description | Discovery (01-prospeo-discover, 02, or 04-theirstack discover, by shape below) | | Example companies to find more of | 01-prospeo-lookalike - the list is **seeds**, not targets | | A target company list (domains) | 01-icp-qualify first, then 03/04 on the survivors | | A list with scrape/signal data | 05-signal-builder | | Named contacts missing emails | 06-resolution-email-person | | Signals + verified emails | email-writer (the chain is done) |

**A domain list is ambiguous input - resolve it before routing.** The same CSV routes two opposite ways: a *target* list gets enriched (03/04), a *seed* list gets expanded (01-prospeo-lookalike). "Here are our 40 closed-won accounts" or "our competitor's customers" is almost always seeds; a conference attendee export or a purchased list is almost always targets. When the framing is genuinely unclear, ask - routing seeds into 03 scrapes the customers they already have.

Inherited data passes through untouched - the chain contract is additive (`headless-gtm-shared/CONVENTIONS.md`): every record keeps its upstream fields, keyed by normalized `domain`.

Step 1 - classify the ICP shape

| Shape | You'll recognize it by | Discovery route | |---|---|---| | **b2b-saas** | Companies a B2B database can filter: industry + size + geo + funding; buyers have titles | 01-prospeo-discover from filters; 01-prospeo-lookalike from seed companies | | **vertical-smb** | Local or owner-operated: studios, salons, clinics, gyms, restaurants, trades, venues - Maps-addressable | 02-apify-maps-discover | | **hiring-defined** | The ICP is an event: "companies that just hired X" or "have an open X req" | Open reqs: 04-theirstack-jobs discover, directly. Past joins: 01 superset + 04 filter (see below) | | **web-scattered** | No database covers them and they're not on Maps: directories, marketplaces, event listings, niche communities | 03-firecrawl-research extract mode on the source sites |

If the shape is genuinely ambiguous, ask one question - "could you find these companies in a B2B database by industry and size, are they local businesses you'd find on Google Maps, or are they defined by something that just happened?" - then commit. Don't run a full interview; one answer plus labeled assumptions beats five questions.

Step 2 - assemble the chain

Default chain per shape. Deviate when the modifiers below say to, and say why in the plan.

| Shape | Chain | |---|---| | b2b-saas | 01 (discover from filters, or lookalike from seeds) -> 01-icp-qualify -> 04-crustdata -> 03 (selective) -> 05 `icp_shape