Build a 21-Agent GTM Pipeline with Claude Skills

Published 10 June 2026 by Yanni Papoutsis

TL;DR: Most go-to-market work fails in the ordering: people write content before positioning and buy ads before analytics. A Claude GTM pipeline fixes the ordering by encoding it as 21 numbered skills inside one plugin: market intelligence, positioning, channel strategy, technical SEO, analytics setup, email infrastructure, blog factory, social content, visual assets, press kit, social distribution, syndication, directories, outreach, ads, landing optimisation, referrals, community, testimonials, lifecycle email, and a growth council. Each skill reads upstream artefacts from a shared outputs/ folder, writes its own artefact, and records a pass or fail verdict in gates/. Downstream stages refuse to run on failed gates, so the blog factory cannot start without locked positioning, and the ads agent cannot spend before tracking exists. The folder tree, a positioning skill example, and the handoff convention are below.

A Claude GTM pipeline is a chain of 21 sequential skills that takes a product from market intelligence to positioning to channel strategy to SEO foundation to content to distribution to analytics, with a gate between every stage so no message ships before the strategy behind it exists. You package it as one plugin and run it stage by stage; this guide gives you the structure, a stage template, and the handoff format.

What is a 21-agent GTM pipeline?

It is the marketing twin of a build pipeline: one plugin, 21 specialist skills, run in sequence with enforced handoffs. Where my 21-agent product pipeline turns a spec into shipped software, the GTM version turns a shipped product into qualified traffic and measurable revenue motion.

The 21 agents, in run order:

00 market-intelligence   07 social-content       14 ads-architect
01 positioning           08 visual-assets        15 landing-optimiser
02 channel-strategy      09 press-kit            16 referral-architect
03 seo-engine            10 social-distribution  17 community-builder
04 analytics-architect   11 syndication          18 testimonial-engine
05 email-architect       12 directories          19 lifecycle-email
06 blog-factory          13 outreach-engine      20 growth-council

The first five stages are strategy and infrastructure, stages 06 to 12 are content production and distribution, stages 13 to 19 are growth motions, and stage 20 is the retrospective that decides what to double down on. The dependency rule is absolute: content stages require gate 01 (positioning) and distribution stages require gate 04 (analytics), because unmeasured distribution teaches you nothing.

Why do GTM agents need gates?

Because marketing failure is usually sequencing failure, and gates make wrong sequences impossible. A gate is a small JSON verdict each stage writes; the next stage starts by reading it and refuses to proceed on FAIL.

Concrete examples of what the gates catch:

  1. The blog factory (06) refuses to write if positioning (01) has no ICP or message hierarchy, preventing generic content.
  2. Social distribution (10) refuses to post if analytics (04) has not defined UTM conventions, preventing untrackable campaigns.
  3. The ads architect (14) refuses to spend if the landing optimiser (15) has no conversion baseline recorded, preventing paid traffic to broken pages.
  4. The growth council (20) refuses to conclude without performance data from stage 19's reports, preventing strategy by anecdote.

How do you build the GTM pipeline step by step?

Scaffold one plugin, write a shared stage contract, then give each of the 21 skills its own checklist and artefact. The mechanics of manifests and packaging are in my pillar on building a Claude plugin from scratch, so this section focuses on the GTM specifics.

Step 1: Scaffold the plugin and shared folders

mkdir -p gtm-pipeline/.claude-plugin
mkdir -p gtm-pipeline/{outputs,gates}
for s in 00-market-intelligence 01-positioning 02-channel-strategy 03-seo-engine; do
  mkdir -p "gtm-pipeline/skills/$s"
done

Step 2: Define the handoff convention

Every stage writes one markdown artefact and one gate file, named by stage number:

gtm-pipeline/
  outputs/
    00_market_intel.md      # competitors, keywords, audience
    01_positioning.md       # ICP, value prop, message hierarchy
    02_channels.md          # channel choices, effort split, calendar
    03_seo_foundation.md    # schema, sitemap, llms.txt, meta rules
    04_analytics.md         # events, UTM rules, funnel definitions
  gates/
    01_gate.json

Step 3: Write the stage skills

Here is stage 01 in full, the stage everything else depends on:

---
name: 01-positioning
description: Positioning stage of the GTM pipeline. Trigger after market intelligence passes. Defines ICP, value proposition, message hierarchy, and competitive angle for all later content stages.
---

# Positioning agent (stage 01 of 21)

Input: outputs/00_market_intel.md
Output: outputs/01_positioning.md
Gate: gates/01_gate.json

Refuse to run if gates/00_gate.json is missing or failed.

Produce, in this order:
1. ICP: one primary persona with role, pain, and buying trigger.
2. Value proposition: one sentence, no superlatives, testable.
3. Message hierarchy: three messages ranked, each with proof.
4. Competitive angle: where we win, where we concede.

Gate criteria: all four sections present, every message has proof,
no claim contradicts outputs/00_market_intel.md.

Step 4: Wire the SEO and content stages to real checklists

Stage 03 should not improvise technical SEO; point it at a maintained checklist skill so every page gets canonical URLs, schema, Open Graph tags, and AEO files like llms.txt. I use my SEO and AI search checklist skill as the reference, and the blog factory (06) inherits the same rules for every draft, including TL;DR blocks and question-format headings. Claims in content stages get held to evidence standards by the anti-hallucination skill, which stops invented statistics reaching published posts.

Step 5: Run, gate, iterate

Install the plugin, then drive stages with scoped prompts:

Run stage 06 (blog factory) of the GTM pipeline for the launch.
Read outputs/01_positioning.md and outputs/03_seo_foundation.md first.
Write outputs/06_blog_batch_01.md and gates/06_gate.json.

Stage 20, the growth council, closes the loop monthly: it reads every gate and the analytics artefact, then writes a keep, cut, and double-down list that becomes the input to the next cycle.

What does each stage actually produce?

Strategy stages produce decisions, production stages produce assets, and growth stages produce running motions; nothing produces "ideas". A useful test: every artefact must be specific enough that a stranger could execute from it.

Stage block Artefact type Example
00 to 04 Decision documents UTM convention table, channel effort split
05 to 09 Assets Drip sequence, blog drafts, OG image specs
10 to 12 Distribution logs Post schedule, syndication map
13 to 19 Running motions Outreach queue, referral mechanics, reports
20 Verdicts Keep, cut, double-down list

Deploy notes: yanni.uk runs on Astro and Cloudflare Pages, so stage 03 artefacts include build-time rules (sitemap generation, redirects, headers) that the Cloudflare Pages documentation covers well.

Frequently asked questions

Do I need all 21 GTM agents for a small product?

No. For a single small product, run 00 to 06 plus stage 20 and skip the rest until traffic justifies them. Keep the numbering and gate format so the dormant stages can switch on later without restructuring.

How is this different from one big marketing prompt?

A single prompt produces plausible marketing copy with no memory of strategy. The pipeline produces artefacts that constrain each other: positioning constrains content, analytics constrains distribution, and the gates make those constraints enforceable rather than aspirational.

Can the pipeline post to social platforms directly?

Yes, through MCP connectors declared in the plugin's .mcp.json, with credentials supplied as placeholders such as YOUR_BUFFER_TOKEN for users to replace locally. The Model Context Protocol documentation explains connector configuration; never ship real tokens inside a plugin.

How often should the growth council stage run?

Monthly is the practical floor, weekly during a launch window. It is the only stage with permission to change earlier artefacts, because strategy edits should happen deliberately in one place, not ad hoc in every stage.

About the author

Yanni Papoutsis builds AI products, automation pipelines, and technical documentation with Claude, and publishes free tooling and guides at yanni.uk.

Next step: Build the product first with the 21-agent product pipeline, then explore 1,000+ free AI tools at yanni.uk/category/all/.

Sources