Claude Code for GTM means running your go-to-market with Claude Code as the operating layer. Each client's strategy, campaigns and history sit as files in GitHub. Skill files tell Claude Code how to do each job. Supabase remembers every lead and reply, and scheduled loops run the work without anyone chasing it.
We run every client account and our own agency this way. Our guide to Claude for GTM explains the Claude brain and why it sits at the centre. This page goes one level deeper: the repos, the split between skills and knowledge, the loops, the memory, the connections and a working day.
The shape below is where we landed after building 160+ GTM systems for clients. Earlier versions cost us a lot of time, and the section on repos explains what we dropped and why.
The Claude Code GTM stack, layer by layer
Claude Code was built for programmers. We put it in the middle of the GTM stack because it reads and writes to every other tool directly. These are the layers around it and the job each one does.
| Layer | What runs it | Its job |
|---|---|---|
| Knowledge | GitHub, one repo per client | Holds the client's foundation, campaigns, decisions and raw comms as versioned files |
| Behaviour | Skill files, in a repo of their own | Tells Claude Code how to do each job, which tools it may open and where it stops |
| Operating layer | Claude Code | Reads the account, runs the skill and opens a pull request with the result |
| Loops | Trigger.dev, n8n and scheduled routines | Fires the work on a schedule or an event, paced and retried |
| Memory | Supabase | The lead bank: every lead, send and reply, locked to one client per query |
| Connections | MCP connectors and tool APIs | Reaches Slack, ClickUp and Google Drive, plus the data, sending and CRM tools |
| Credentials | 1Password | Holds every key, while the repos only hold the path to it |
| Front end | Our console, an add-on | One screen over all of it for the people running the accounts |
The data, sending and CRM tools have their own guide: our GTM tech stack map, stage by stage. Prospeo, BounceBan, RB2B, EmailBison, HeyReach and Attio all sit there. This page covers the layers that turn those tools into one system.
Four repos, split by how fast each one changes
Claude Code for GTM starts with where the files live. Every client is a GitHub repo, and what took us longest was deciding what does not go in it.
The two obvious options each cost something. One repo for the whole company puts unrelated work in the same merge path. Every change gets riskier as the repo gets busier. One repo per client with the skills copied inside means fixing the same skill once per client, and the copies drift apart.
So we split on two questions: how often a thing changes, and who is allowed to write to it. That gave us four repos.
| Repo | What it holds | How fast it moves |
|---|---|---|
| Kinetyca OS | The knowledge: methodology, playbooks and how we think about the work | Slowly: the method can sit untouched for a month |
| Kinetyca Skills | The behaviour: every skill Claude Code runs | Several times a week, faster than anything else |
| Kinetyca Shared | The config every repo reads, and the path to the credentials | When a setting or a tool changes |
| One repo per client | That client's GTM, isolated from every other client | On the client's own rhythm |
The write rules are what hold the split in place. A skills change waits for a person to approve it, because one bad skill reaches every client at once. Client work moves at the client's pace and never waits on a skills release.
The payoff shows when a skill breaks. The fix goes into one repo, every account runs the corrected version, and nobody touches client data to ship it.
What lives in a client repo
Every client repo is stamped from the same template, so anyone can open any account and find things without asking. There is no code inside. It holds what we know about the client and what we have done for them.
Three rules keep the repo usable a year later.
- One home for each fact. The broad ICP lives in the foundation. The narrow segment a campaign targets lives in that campaign's folder. When the ICP moves, one file changes.
- Folders never move. There are no version numbers in folder names and no archive folder. A campaign's status sits at the top of its file, because a moved folder breaks every reference to it.
- The record only grows. Transcripts and Slack pulls go in exactly as they came out. Each decision gets a file the day it is made, naming who made the call and what it replaces.
Claude Code works in the repo the way we do. It branches, does the work and opens a pull request. It cannot push to main, so a person reads every change before it lands.
Before it answers a question about a client, it reads the whole account. The foundation tells it what we promised. The campaign tells it what is live. The decisions stop it proposing what we already ruled out, and the comms keep it close to what the client said.
That account-level context is what we call the client's GTM brain. The time goes into the decision, since nobody has to reconstruct the account first.
Skills versus the knowledge base
The most important split in this setup is between how we work and what we know. Skills hold the how. The client repo and Kinetyca OS hold the what. A skill never carries a client's facts, and a client repo never carries steps.
| Goes in a skill | Goes in the knowledge base |
|---|---|
| The steps for one job, in order | The client's offer, ICP, personas and proof |
| Which tools Claude may open, and which it must leave alone | Which campaigns are live, and the segment each one targets |
| Which knowledge to read before starting | Every decision, with its date and owner |
| What the skill is never allowed to do | Raw comms from Slack, calls and email |
| Where it stops and hands over to a person | Our methodology and playbooks, in Kinetyca OS |
The never-allowed rules carry a lot of the weight. 90 of our 104 skill files carry at least one rule like that. Any skill that can spend money, send a message or change a live campaign ends at a person.
How a skill file is built, and the 15 we would start a team with, are in the best Claude skills for GTM. Every skill we publish is in our Claude skills library.
How the loops run: Trigger.dev, n8n and routines
A skill only runs when something calls it. Loops call it without a person having to remember. We run three kinds.
- Trigger.dev for jobs at volume. It decides what fires and when. A list build queues each provider request as its own task run, paced, with retries per request. One slow provider no longer holds up the whole batch.
- n8n for the glue. It handles hand-offs between tools where the path is fixed and needs no judgement.
- Daily routines for context. They pull what happened in Slack, ClickUp and Google Drive into the client repos. Each new Slack reply arrives as its own commit, so Monday's repo already holds Friday's client thread.
Clay still runs inside outbound, for the enrichment waterfall and signal layering. It is one step inside the loop, and Claude decides what runs around it. Where the line between Clay and Claude Code falls changes from build to build.
Supabase is the memory
Supabase is the lead bank. Every lead, send and reply lives there. Every query is locked to a single client, so data cannot cross from one account to another.
It is also where the truth lives. The state file in each client repo is a generated view of the lead bank, rebuilt by a reconciler. Nobody edits it by hand, so the repo and the database never disagree about what is live.
Memory is what carries one campaign's lessons into the next. It also changes what a list build costs. The build checks the client's existing bench in Supabase first, then calls new providers in a set order. A lead we already hold is used again before any credits go on a new one.
How Claude reaches the tools, and what it never holds
Claude reaches the rest of the stack in two ways. Workspace tools such as Slack, ClickUp and Google Drive connect through MCP connectors. Inside a session, Claude can read a thread or update a task.
The data, sending and CRM tools connect through their APIs, called from skills and Trigger.dev tasks. That covers EmailBison and Smartlead for email, HeyReach for LinkedIn and Attio for the pipeline.
No password or API key sits in any repo. Each repo holds a path, and the key resolves from 1Password at the moment a call is made. What comes back to Claude is the response, with the key left out.
Spend has a gate of its own. Every provider carries a spend ceiling, and a purchase above the cap needs a second confirmation before any money moves.
A working day on Claude Code
This is an ordinary weekday across our client accounts. The early steps run before the team starts, and anything that needs judgement waits for a person.
- 01The routines catch upThe daily routines have already pulled new Slack threads, call transcripts and task updates into each client repo, one commit each.
- 02Every campaign gets a verdictAt seven, the Daily Performance Monitor gives every live campaign a kill, stay or scale call. The thresholds live in code, so two identical campaigns never get two different verdicts.
- 03A person decides what to act onThe monitor only reports. Moving sending capacity runs through Stop, Leave or Scale, which waits for a person to confirm.
- 04The console ranks the accountsOne screen lists every client worst first, with each campaign's lead runway and each inbox's health. A drifting campaign shows up the day it drifts, without opening four dashboards.
- 05The team works in the reposA GTM engineer opens Claude Code in a client repo and runs a skill, such as a list top-up or a new segment. Claude reads the account, works on a branch and opens a pull request.
- 06Heavy jobs go to the queueA list build runs on Trigger.dev in the background, paced, while the engineer moves on to the next account.
- 07A person approves every sendCampaigns land in the sending tool as drafts, and replies come back drafted. Nothing reaches a prospect until someone signs it off.
- 08The retro feeds the systemWhat a campaign taught us goes into the client's record. A lesson that holds across clients goes into a skill, so the next account starts from it.
Two things make Claude Code for GTM work day to day. Every account has the same shape, and every irreversible step has a person on it. Take either away and the morning turns back into four tabs and a spreadsheet.
Where to start with Claude Code for GTM
We built ours in a fixed order, and the order is the reason it holds. Each layer works because the one under it already does.
- The foundation. One repo per client, written down before anything is automated.
- The guardrails. Keys in a vault, sends behind a sign-off and spend behind a cap.
- The daily run. The routines, the morning verdicts and one screen to read them on.
- The retro loop. Lessons go into the knowledge base, and the knowledge base improves the skills.
Start smaller than this page. Pick one tool per layer, and add a second only when the first runs out.
How much of this a team needs depends on its size. A founder working alone runs a far lighter setup than a twenty-person team. Our guide to Claude for sales walks through the setup at each size.
We also build and run this system for clients.
What infrastructure do you use to plan, set, orchestrate, and report all of these campaigns?
GitHub holds each client's plan as files, and Claude Code runs the work from skill files. Trigger.dev and n8n run the loops, and Supabase holds every lead, send and reply. Reports are built with Claude and posted to Slack, with a console on top for the team.
Where do sends and replies get recorded?
Every send and reply lands in Supabase first, locked to that client. From there it writes back to the CRM through its API, so the sales team can see who has been contacted. We mostly work in Attio and HubSpot, and any CRM with an API can be connected.
What is the interface behind what you're selling?
There are two. Clients get a login to the sending tool's workspace, where they can see every email going out and every campaign. We also built a front end over the Claude brain that shows the dashboards, the leads and the plan of action in one place.
What am I doing day to day to interact with the system?
You spend little time on the running itself. You review what needs a decision: the segments, the offers and anything about to go out. We hold a strategy session once a week and talk in a shared Slack channel in between.
Software, accelerator and startup background. Runs the GTM architecture side: how the system is designed, what it is built on, and where AI actually earns its place.
LinkedIn ↗YouTube ↗