# Gtm > Phased go-to-market for startup products. Builds a GTM playbook from upstream artifacts (validation-canvas, pitch-deck, brand-workshop), produces multi-channel content, schedules cadenced tasks, enforces compliance (CAN-SPAM/GDPR/FTC), emits handoff events. Trust ramp P1→P2→P3 (read-only → scheduled → autonomous). Project-local `.gtm/`. Kill switch via HALT file. Triggers on "set up GTM", "create… - **Type:** Skill - **Install:** `agentstack add skill-sorawit-w-agent-skills-gtm` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [sorawit-w](https://agentstack.voostack.com/s/sorawit-w) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [sorawit-w](https://github.com/sorawit-w) - **Source:** https://github.com/sorawit-w/agent-skills/tree/main/skills/gtm ## Install ```sh agentstack add skill-sorawit-w-agent-skills-gtm ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # GTM > **🚧 BETA — read before relying on it.** First release: 2026-05-06. > Iteration-1 evals scored 100% with-skill (24/24) vs 27.8% baseline (7/24, > +72pp delta across first-run-with-artifacts, cold-start, and kill-switch > tests). Those evals validate **structural reliability** — `.gtm/` file > structure, helper-function kill-switch pattern, handoff event vocabulary, > compliance gate refusals. They do **NOT** validate real founder workflows > on a real startup project — that dogfooding is the next milestone before > graduating to v1. > > **What this means in practice:** treat outputs as drafts to review, not > artifacts to ship. The first founder to actually run this on a live > project will surface issues the evals couldn't see. Breaking changes are > possible before v1 — particularly around the wizard-confirmation gate > (whether the playbook auto-runs vs. waits for explicit approval), the > exact handoff event payload shapes, and the trust-ramp promotion criteria. > > **What's known to work** (per evals): auto-detection of upstream > artifacts, `.gtm/config.yaml` + `.gtm/state.json` creation, P1 mode > default, brand-voice consumption from `DESIGN.md`, the architectural kill > switch (HALT file + helper-function wrapper), region-adapter loading, > compliance-gate refusal on non-compliant content, handoff event emission. > > **What's NOT yet validated:** content quality on real brands (evals only > checked structural keyword presence), graceful degradation when > `marketing:*` is missing, multi-region adapter behavior under real > non-English content, sustained P2/P3 operation over weeks, scheduling > integration with the harness's actual scheduler. > > File issues at https://github.com/sorawit-w/agent-skills/issues with the > `gtm` label. Get a startup product to market through online and offline channels. This skill takes a founder's product context (canvas, deck, brand voice) and turns it into **a phased GTM playbook + per-channel content + scheduled rituals + a trust-ramped execution loop with compliance gates and an architectural kill switch**. Designed-for-orchestration: every action emits a structured event so a future virtual-company agent fleet (support, sales, engineering workers) can read GTM's outputs as inputs. The skill's value cut is *founder leverage*, not *founder replacement*. Pretend otherwise and you'll burn the founder's accounts, reputation, and budget. ## What this skill produces All artifacts live under `/.gtm/`. Created at first run; persists and grows over time: ``` .gtm/ ├── config.yaml Channels, budgets, North Star, brand voice ref (in git) ├── state.json Status, last-digest timestamp, counters (in git) ├── HALT Kill flag — checked before every external action (in git) ├── secrets.local.yaml API tokens, credentials (gitignored) ├── brand-voice.md Cached voice (or pointer to brand-workshop output) (in git) ├── digests/ Daily + weekly digest archives (in git) │ └── 2026-05-05-weekly.md ├── drafts/ Content drafts before publish (in git) │ └── twitter/2026-05-05-launch-thread.md └── (events written to /.workspace/events/YYYY-MM.jsonl) ``` Plus: 1. **Discord digests** — daily and weekly summaries posted to `#agent-digest` when a Discord MCP is configured; otherwise written to `.gtm/digests/` and surfaced as copy-paste-ready blocks in chat. 2. **Discord escalations** — high-signal blocks posted to `#agent-escalation` when a budget triggers, a metric breaches its floor, a new channel is used for the first time, or a crisis signal fires. 3. **Scheduled tasks** — registered via the `schedule` skill at first-run for daily metrics pull, daily digest, weekly retro, and 6-hour budget check. 4. **Handoff events** — append-only JSONL at `.workspace/events/YYYY-MM.jsonl` so future workers (support, sales, eng) can consume `lead.captured`, `content.needs_eng`, `crisis.detected`, and other events GTM emits. ## What this skill is NOT - **Not an auto-poster.** First use of any channel requires an explicit human gate. After one successful manual review per channel per project, the founder can opt the channel into autonomous mode for that project. Never global, never silent. - **Not a relationship surface.** Community replies, 1:1 outreach, DMs to real humans — the skill drafts, never sends. Astroturfing rules apply. - **Not a CRM.** GTM emits handoff events when leads are captured, but lead management, scoring, and pipeline progression are downstream concerns. - **Not a brand identity tool.** Logo, tagline, brand strategy → use `brand-workshop`. GTM consumes its output, never generates it. - **Not a pitch-deck builder.** Investor-ready decks → use `pitch-deck`. GTM reads pitch-deck content for messaging, never produces slides. - **Not validation work.** Lean Canvas / VPC → use `validation-canvas`. RAT → use `riskiest-assumption-test`. GTM consumes their outputs for ICP and positioning. - **Not adversarial review.** "Will this GTM plan get torn apart by a VC?" → use `startup-grill`. - **Not a one-shot content tool.** If you just need a single LinkedIn post and don't care about state, voice consistency, or scheduling, route to `marketing:content-creation` (or `marketing:draft-content`) directly. ## Skill Boundaries | Want this | Use this | |---|---| | Multi-channel campaign with state, voice, scheduling | **`gtm`** (this skill) | | One-shot post for one channel | `marketing:content-creation` / `marketing:draft-content` | | Email drip sequence with branching | `marketing:email-sequence` (GTM dispatches to it for sequence work) | | Brand voice review on existing content | `marketing:brand-review` (GTM runs this as its compliance gate) | | Performance report for a finished campaign | `marketing:performance-report` (GTM dispatches as part of weekly retro) | | SEO audit | `marketing:seo-audit` | | Competitor positioning research | `marketing:competitive-brief` | | Launch identity (logo, tagline, brand) | `brand-workshop` | | Investor pitch deck | `pitch-deck` | | Stress-test the GTM plan adversarially | `startup-grill` | **Pattern:** GTM is an *orchestrator* over the `marketing:*` plugin skills. When those skills are installed (default in Claude Cowork/Code), GTM dispatches work to them via `sub-agent-coordinator` and adds the layers they don't provide: state, scheduling, compliance, kill switch, handoff events, region adaptation. When `marketing:*` is not installed, GTM falls back to inline prompts (worse output quality, still functional) — see `references/marketing-fallback.md`. --- ## Phase 0: Path resolution + first-run detection Run before any other work. Three steps. ### Step 0.1 — Resolve the GTM root The GTM root is `/.gtm/`. Detection order: 1. **Explicit `gtm_root` arg** (passed by future orchestrator) → use as-is. 2. **`GTM_ROOT` env var** set → use it. 3. **Default** → `/.gtm/` where `` is the project's working directory. Multi-project case: each project has its own `.gtm/` in its own repo. If the working directory has multiple `.gtm/` siblings (monorepo of projects), GTM asks the founder which project this run is for. Default detection: assume single-project layout — most founders use one repo per startup. ### Step 0.2 — First-run vs subsequent-run detection - **`.gtm/config.yaml` does NOT exist** → first run. Proceed to Phase 1 (wizard). - **`.gtm/config.yaml` exists** → subsequent run. Load config + state, skip the wizard, proceed to Phase 3 (execution loop). - **`.gtm/HALT` exists** → halted. Read the HALT file's reason if present, surface to founder, refuse all external actions until founder removes the file. Founder can still run gtm in dry-run-only mode for planning. ### Step 0.3 — Auto-detect upstream artifacts Look for these in the project root and one level deep — use silently if found, ask in the wizard if not: | Artifact | Source skill | GTM uses it for | |---|---|---| | `validation-canvas.md` | `validation-canvas` | ICP, channels, value prop, stress tests | | `assumption-test-plan.md` | `riskiest-assumption-test` | Validated channel hypotheses | | `deck.html` / `pitch-deck/*.html` | `pitch-deck` | Positioning, messaging, narrative | | `DESIGN.md` / `brand-workshop` output | `brand-workshop` | Voice, tokens, tone profile | | `kit-manifest.json` | `startup-launch-kit` | Pipeline state, intake-answers cache | If the founder has `kit-manifest.json` from a prior pipeline run, GTM appends its own entry there (atomic write) so the manifest reflects post-launch state. If the manifest doesn't exist, GTM does NOT create it — that's the orchestrator's job. --- ## Phase 1: First-run wizard (7 questions) Run only on first invocation per project. The wizard surfaces the seven decisions the skill cannot make for the founder. Asked one at a time — never batched into a single mega-prompt — because each answer affects what the next question should look like. See `references/first-run-wizard.md` for the full script and answer-handling. Summary: 1. **Project identity** — name + slug (auto-detected from `package.json#name` or parent dir if possible; confirms with founder). 2. **North Star metric** — pick one: weekly signups / weekly active users / paid users / something custom. Used as the one number every digest leads with. 3. **Active channels** — multi-select from B2C-weighted defaults (X, TikTok, Reels/IG, YouTube, blog/SEO, Reddit, Discord/community, email, partnerships, paid). Founder can add custom channels. 4. **Brand voice source** — auto-detected if `DESIGN.md` or brand-workshop output exists; else asks: paste a voice description / point to existing docs / *offer to invoke `brand-workshop` if installed*. 5. **Measurement tool** — tool-agnostic; user picks Plausible / PostHog / GA4 / Mixpanel / Native-only / Custom. The skill records the choice and ships with named-but-not-required adapters. 6. **Digest cadence + Discord setup** — daily/weekly/both; channel names for `#agent-digest` and `#agent-escalation` (or copy-paste fallback if no Discord MCP installed). 7. **Region(s)** — primary + any secondary regions for content. Each region loads a reference file from `references/regions/{code}.md` with cultural notes, platform map, and local regulations. After wizard completion: write `config.yaml`, write initial `state.json`, create empty `digests/` and `drafts/` folders, append secrets path to `.gitignore` and inform the founder, register scheduled tasks via the `schedule` skill if the founder opts in. --- ## Phase 2: Operating modes (the trust ramp) GTM operates in one of three modes. The mode is config-driven and ramps over time — it cannot skip levels. ### P1 — Playbook mode (default first run) - **Reads:** auto-detected upstream artifacts + wizard answers - **Writes:** `.gtm/` files, content drafts in `.gtm/drafts/`, daily/weekly digests in `.gtm/digests/` - **Does NOT:** call any external API, send email, post to social, spend ad budget - **Escalation:** Discord/copy-paste only for surfacing drafts the founder reviews - **Promote to P2 when:** founder explicitly sets `mode: p2` in config.yaml AND the relevant MCPs are configured (Notion, Discord, etc.) ### P2 — Scheduled execution mode - All P1 capabilities plus: - **Reads:** metrics from connected MCPs (PostHog, Plausible, native platforms via supermetrics MCP, etc.) - **Writes:** state updates with metric counters; posts digests to Discord via MCP - **Does:** schedule cadenced tasks via `schedule` skill; queues offline manual-tasks in Calendar/Notion - **Does NOT:** publish content to social/email/ads — drafts still require human review per-channel-per-project for the first run of each channel - **Promote to P3 when:** founder explicitly sets `mode: p3` AND has approved at least one round of content per active channel in P2 ### P3 — Autonomous-with-escalation mode - All P2 capabilities plus: - **Does:** publish content to channels the founder has opted in (per-channel flag in `config.yaml#channels.{name}.autonomous: true`); spend ad budget up to configured caps; send email up to caps - **Always escalates:** budget thresholds, metric breaches, new region first-touch, sentiment/crisis signals, anything labeled `confirm_required` in the trigger table (Phase 4) **Skipping the trust ramp is forbidden.** A `config.yaml` that declares P3 without a P2 history is an error condition — GTM refuses and explains why. This is not negotiable. Empirically, founders who skip P2 burn either an account, their reputation, or several thousand dollars in ad spend within the first week. --- ## Phase 3: The execution loop This is what happens on every (non-first-run) invocation. Order is fixed and the helper-function wrappers are not optional — they are the architectural enforcement layer. ``` read_state() → load config.yaml + state.json plan_cycle() → decide what work this cycle needs for each work_item: require_active() → checks HALT file + state.status check_dry_run() → if dry-run mode, log and skip external check_budget(category, cost) → refuses if over cap, escalates if near cap check_compliance() → CAN-SPAM/GDPR/FTC/TOS/COPPA refusals check_first_use_gate(channel) → human-review required for first run on channel dispatch_to_marketing(...) → fan-out to marketing:* (or inline fallback) region_adapt(output) → wrap with regional context, route i18n execute() | queue_manual() → MCP call OR queue Calendar/Notion task log_event() → append to .workspace/events/YYYY-MM.jsonl aggregate_digest() → produce daily/weekly summary post_digest() → Discord MCP or copy-paste fallback ``` Every external action must pass through `require_active()`, `check_dry_run()`, `check_budget()`, `check_compliance()`, and `check_first_use_gate()` before firing. The agent does not decide whether to honor these — the helper wrappers enforce. See `references/kill-switch-pattern.md` for the helper-function pattern. The compliance gate is `marketing:brand-review` when installed; otherwise an inline prompt-based check. The compliance gate refuses non-compliant output with a clear reason and emits a `crisis.detected` event if the gate refuses three times in one cycle (signals a misconfigured campaign or a confused founder request). --- ## Phase 4: Escalation triggers | Trigger | Severity | Auto-pause? | Channel | |---|---|---|---| | Budget approached (>80% of cap) | warn | no | `#agent-escalation` | | Budget hit | block | no — action refused, future actions in category blocked | `#agent-escalation` | | Metric below floor (per-channel or North Star) | warn | no | `#agent-escalation` | | First-time using a new channel | confirm | yes (until ack'd) | `#agent-escalation` | | New region first-touch (GDPR-relevant) | confirm | yes (until ack'd) | `#agent-escalation` | | Anomaly: >2σ deviation from 4-week baseline | warn | no | `#agent-escalation` | | Sentiment cliff / crisis signal | block | yes — full pause | `#agent-escalation` | | Platform error (account suspended, rate-limited) | block | yes — that platform only | `#agent-escalation` | | Legal flag (action violates CAN-SPAM/GDPR/FTC/TOS) | block | no — action refused | `#agent-escalation` | | HALT file detected mid-run | block | yes — full halt | `#agent-escalation` | | Daily digest | info | no | `#agent-digest` | | Weekly retro | info | no | `#agent-digest` | **Two-channel discipline.** Digests go to `#agent-digest` (low noise, scheduled). Escalations go to `#agent-escalation` (high signal, real-time, mention-on-block). If both went to the same channel the founder would mute it within a week. --- ## Phase 5: Ha … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [sorawit-w](https://github.com/sorawit-w) - **Source:** [sorawit-w/agent-skills](https://github.com/sorawit-w/agent-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-sorawit-w-agent-skills-gtm - Seller: https://agentstack.voostack.com/s/sorawit-w - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.