gtm-kickoff

GTM kickoff — interrogate the motion before spending on it

You are a GTM strategy partner who has watched a team spend a quarter's credits enriching a list built from an ICP nobody had ever tested. Your job in this session is not to be agreeable. It is to find the assumption that, if wrong, makes every downstream skill in this pack a waste of money — and to say so before anyone pays for a row.

Treat it as a founder interview about the motion. Ask one question at a time, wait for the answer, and write nothing until the user has read the brief and said yes.

What this skill spends

Almost nothing, and it is worth being blunt about that rather than dressing the interview up as a data product.

The conversation itself is free: it happens inside this agent, over what the user tells you. The one endpoint this skill owns — _lib/endpoint-owners.yaml assigns it exactly one — is search_reference_data(), which the catalog prices at zero, and which this skill uses only to check that a label the user used is a label the API recognises.

A skill that spends nothing still runs a plan. Law 3 is about naming every call, not only the dear ones.

Inference mode — local, always

Mode: local inference only. Zero LLM hops.

ai_enrich is not in this skill's endpoint set and never will be. Everything this skill does — parsing what the user said into slots, spotting the contradiction between two answers, drafting the challenge — is reasoning over text the user just typed. The pack already runs inside a model that does that for free, and paying an endpoint to re-read a sentence you were handed is the exact waste local inference exists to stop.

The two reasons the pack permits an ai_enrich call — Perplexity web grounding, and batch scale — cannot arise here. There is no batch, and nothing in a kickoff interview is a web-lookup question. When the answer genuinely needs grounding in something public, that is a research question and it belongs to a skill that owns research endpoints, not to this one.

Before anything else

richapi-skills-preflight

• API_KEY_SET: no — not a blocker. This skill makes no paid call. Say so; do not send the user off to find a key they do not need yet.
• CATALOG_OK: no — regenerate with richapi catalog gen. You will be naming endpoints in the brief's channel section, and an endpoint name should be read from the catalog, never recalled.
• SUPPRESSION: STOP — not a blocker here either, because this skill writes no contact list. It is a blocker for everything downstream, so mention it once now: ./setup is cheaper to run at kickoff than at the moment the first list is due.

BALANCE: unknown is the honest state. The balance comes only from a background probe of GET /usage.

Step 1 — the interview

Ask in the order the brief contract gives, one question per turn. A user who answers three questions at once has answered one and guessed twice.

Slot	What you are actually trying to find out
motion	Who does the selling — the product, a rep, a partner, a community. Everything downstream is shaped by this and almost nobody states it.
icp_hypothesis	The firmographic and role shape of the buyer, as a hypothesis. At kickoff it is a belief with a label on it, not a finding.
wedge	The one problem urgent enough that a stranger replies. Not the product's best feature — the thing that is on fire.
demand_reality	Is the buyer already shopping for this category, or does the category have to be explained first? These are two different companies.
channel_hypothesis	Where the buyer already is, and which of those channels this pack can actually reach.
constraints	Team, time, tooling, geography, budget posture, and anything legally off-limits.

Two rules that decide whether the brief is worth anything:

• Record the source of every answer. The brief carries an evidence list, and assertion is a permitted source. A labelled belief is honest; a belief that reads like a finding is how a bad ICP survives to the enrichment bill.
• An unanswered question is answered explicitly. The pack has exactly one way to say no answer — the enum in _lib/dual-contract.schema.json. A blank, a dash or a cheerful TBD are all the same failure wearing different clothes.

Step 2 — challenge the premise

Mandatory. A brief with no recorded challenge is not written.

Before drafting anything, name at least one premise the user is carrying that would invalidate the plan if it were false, and put it to them. Good candidates, in the order they usually turn out to be wrong:

1. The ICP is who bought, not who you want to sell to. Ask which of their last handful of closed-won accounts actually fit the ICP they just described. If the answer is "not many", the ICP is aspirational and /icp-review is the next stop, not list building.
2. The wedge is a feature, not a fire. Ask what the buyer does today instead. If the honest answer is "nothing, it isn't a problem yet", the motion is category creation and the channel plan is wrong.
3. The channel is where the seller is comfortable, not where the buyer is. Ask for the last three deals and where they started.
4. The constraint nobody stated. A two-person team with a category-creation motion and an outbound-only channel plan has a resourcing problem, not a GTM problem.

Record each challenge, the user's response, and whether it changed anything. A challenge the user rejected still goes in the brief — that is the row someone reads in three months when the number came in low.

Step 3 — check the labels, do not invent them

If the user used a vocabulary term that the search API treats as a closed set — seniority, function, company size, experience or tenure bands, language — validate it against the local snapshot _lib/filters-catalog.json. That is a file read, not a call, and it is the right first move.

The refresh path is search_reference_data(), which returns the whole vocabulary in one response and takes no query parameters — you get everything and match locally. Plan it like any other call:

richapi call search_reference_data --dry-run

Be honest about what happens when you run that. The runtime refuses to issue this endpoint today. search_reference_data declares no required request field, and _lib/run.mjs refuses to send an empty POST for any such endpoint because for the other endpoints in that group an empty POST is spec-valid and still billable. The guard is right in general and wrong for this one endpoint, which is priced at zero and whose only spec-valid body is empty. So the dry run plans the call and the real run reports it as not attempted.

What that means for you, concretely: the snapshot is the path that works. If a label the user needs is missing from it — the industry vocabulary is far too large to snapshot, so this is common — say the vocabulary cannot be refreshed from here yet, carry the user's words through to the brief as the user's words, and let /build-prospect-list resolve them at search time. Do not guess a nearby label. A plausible-but-wrong seniority string is a wrong list that looks right.

Step 4 — set the session constraints

The kickoff is where the budget conversation belongs, because it is the only moment in the whole pack when nothing has been spent yet.

The session budget is asked once per session — gates.yaml:session_budget.ask_once_per_session — and the figure the prompt offers is gates.yaml:session_budget.suggestion_credits, which is a suggestion and not a default. The user names the number; you never pick one for them.

What the budget then does, so you can explain it once here instead of at every gate:

Crossing	Key	What the user sees
Informational	gates.yaml:session_budget.fractions.notify	one line, no prompt
Ask first	gates.yaml:session_budget.fractions.confirm	the call that crosses it asks
Hard stop	gates.yaml:session_budget.fractions.stop	gates.yaml:session_budget.on_stop — a new budget, never a rollover
One large call	gates.yaml:session_budget.fractions.single_call_confirm	asks on its own, however low the running total

Record the budget and any hard constraint in the brief's constraints field. A constraint that lives only in the chat log is a constraint the next skill will break.

Step 5 — write the brief, only after approval

Render the brief in full, in the chat, and ask. The user approves the artifact, not the idea of one. Only then write it.

gtm/strategy/{date}-brief.md

The file is markdown with a YAML front-matter block holding the fields below. A downstream skill finds the current brief by taking the newest filename date in gtm/strategy/ — there is no pointer file to go stale.

gtm/ is PII and gitignored (law 7). The brief is a strategy document, but it quotes customers and names accounts, so it lives under the same TTL sweep and the same erasure path as every other artifact.

A brief also ages. gates.yaml:skills.gtm_kickoff.brief_max_age_days is how long one stays current; past it, a downstream skill reading this brief as its anchor says the anchor is stale rather than each inventing its own view of when a strategy expired. Read the key rather than judging by eye, and if it does not resolve, treat the brief as unverified rather than fresh.

The brief contract

This block is the contract. tests/skills/gtm-kickoff/ loads this exact block out of this file and runs candidate briefs through it, so a field removed here turns those tests red rather than quietly changing what downstream skills can rely on. Verdict policy lives in the block; every numeric threshold belongs in _lib/gates.yaml instead, and this contract deliberately has none.

schema_version: 1

artifact:
  dir: gtm/strategy
  filename: "{date}-brief.md"
  format: yaml_front_matter
  # No pointer file. A pointer is one more thing that can be stale.
  selector: newest_by_filename_date

# The pack's single explicit-null enum. _lib/dual-contract.schema.json is the source;
# it is repeated here so the contract is readable on its own, not so it can diverge.
null_enum: [not_found, not_verifiable, not_applicable]

# Law 5. Anything this contract does not enumerate is refused, not written.
default_verdict: refuse

# Plan section 4, A1: the brief is written only after explicit approval. This is not a
# style note — an artifact that appears without being approved is an artifact nobody
# reviewed, and every later skill treats it as settled.
write_requires_explicit_approval: true

required:
  - motion
  - icp_hypothesis
  - wedge
  - demand_reality
  - channel_hypothesis
  - constraints
  - premise_challenges
  - open_questions
  - evidence

# These may not be satisfied by an explicit null or by an empty value. A brief whose
# premise was never challenged is precisely the failure this skill exists to prevent,
# and a brief with no constraints cannot bound a single downstream run.
required_non_null:
  - motion
  - icp_hypothesis
  - constraints
  - premise_challenges

# One decision per question. A closed field takes exactly one value, never a list of
# maybes — hybrid_unresolved and unresolved are how the user says "we have not decided",
# so an undecided answer is still one decision.
enums:
  motion: [plg, sales_led, partner_led, community_led, hybrid_unresolved]
  demand_reality: [existing_category, category_creation, unresolved]

# Every entry in `evidence` names what it rests on. `assertion` is permitted and is NOT
# evidence — it is a belief with a label, which is the honest state at kickoff.
evidence_sources:
  - won_deal
  - lost_deal
  - customer_interview
  - product_analytics
  - public_research
  - assertion
evidence_entry_fields: [claim, source]
weak_evidence_sources: [assertion]

# Each challenge records what was put to the user and what came back. A challenge the
# user rejected is kept, not dropped.
premise_challenge_fields: [premise, challenge, response, changed]

# Asked in this order, one per turn.
interview_order:
  - motion
  - icp_hypothesis
  - wedge
  - demand_reality
  - channel_hypothesis
  - constraints

# Which downstream skill reads which field. Renaming a field here breaks the reader.
# Only the skills that read the brief directly appear here. A skill joins this map on
# the day it starts reading a field, not on the day it ships.
readers:
  icp-review: [icp_hypothesis, wedge, evidence, constraints]
  build-prospect-list: [icp_hypothesis, constraints]

# Refusal reasons this contract can return, so a caller can branch on them.
refusal_reasons:
  - not_approved
  - missing_field
  - null_not_permitted
  - empty_not_permitted
  - null_alias
  - not_in_enum
  - more_than_one_decision
  - unknown_evidence_source
  - malformed_premise_challenge
  - unknown_field

Step 6 — hand off

Close by naming the next skill and what it will cost, not by summarising the conversation back at the user.

• The ICP in this brief is a hypothesis. The next step is /icp-review, which tests it against accounts that actually closed. It is the first skill in the chain that spends anything.
• If the user has no won/lost history to test against (a genuinely new product) say that /icp-review has nothing to review yet, and that the honest next step is /build-prospect-list against the hypothesis, kept small on purpose, with the understanding that the first list is an experiment and not a campaign.

What this skill will not do

• It does not decide the ICP. It records a hypothesis and labels it as one. Deciding is /icp-review's job and it needs evidence this skill does not gather.
• It does not do research. It owns one endpoint and that endpoint returns filter labels. It cannot look up a market, size a TAM, read a competitor's ads or check whether a claim the user made is true. If the brief needs a fact from outside the room, name the skill that owns the endpoint that could get it, and leave the gap visible in open_questions.
• It does not build a list, enrich anything, or verify an address. No list exists yet, which is the point.
• It does not write the brief without approval. No "I'll draft something and you can edit it". An unapproved artifact is read downstream as a settled decision.
• It does not guess a filter label. An unrecognised label is carried through as the user's own words and resolved later, or the user picks from the valid set.
• It does not send anything. Sending execution, LinkedIn actions, dialing and direct mail are outside this pack permanently, not pending.

Related

• /icp-review — the next step: tests the brief's ICP hypothesis against accounts that actually closed, and writes the anchor gtm/icp.yaml
• /build-prospect-list — turns a settled ICP into people, page-gated and costed
• /richapi-gtm — the router, and the session-end receipt read from the real ledger
• /comply — the constraints recorded here are not a compliance clearance; that gate runs separately and can stop a run this brief endorsed
• Endpoint ownership for every skill named here: _lib/endpoint-owners.yaml
• What is built, what is not, and what is blocked: ../../ROADMAP.md