GTM Brain

A Claude Code harness for running your Day AI workspace like a GTM operating system.

You don't need a Day AI account to start. The harness works in two modes, and the first one is open to anyone:

1. Make it your team's private repo. Do this once, as one of the operators who will run it:

   npx skills add day-ai/gtm-brain --global

   Then run /setup-gtm-brain. It creates the complete private team repo and retains day-ai/gtm-brain as upstream. Add the people who will run the harness as GitHub collaborators. Keep it private: it will hold your strategy, privacy decisions, and candid notes.

2. Open the folder in Claude Code and run /start. With no workspace connected, it drives the map-your-gtm initiative: guided discovery that maps your tech stack, strategy, people, privacy posture, and agent fleet, and scopes a first-win pilot for you or a handful of teammates.

3. Feed it what you have. Drop your GTM docs, CRM export, and org chart in discovery/inbox/; point it at anything you've already taught Claude (a Project, a CLAUDE.md, existing skills). It reads before it asks.

4. Walk out with the payload. A designed agent fleet with costs, a rollout plan, privacy guidance captured (how the settings work, plus a recommended setup per persona), and a deployable configuration in rollouts/preflight/. When you do sign up, setup is an apply step, not a project.

5. Authenticate the Day AI MCP server (approve the day-ai server, complete the OAuth flow). You'll need to be an Owner or Admin of your workspace.
6. Run /start — it detects the connection, reconciles anything you mapped pre-signup against the live workspace, and drives what's next: /implement preflight to apply your payload (first-win slice first), or the default bootstrap initiative on a fresh start.

That's it. Details below.

This repo is a working example of how a go-to-market team can use Claude Code plus the Day AI MCP server to do four things well:

0. Map — before you even have a workspace: discover your tech stack, strategy, people, and privacy posture, design your agent fleet, and build the configuration payload that makes signup day an apply step.
1. Plan — turn your company's goals, your revenue strategy, and the concrete outcomes you're driving toward into living documents that an agent understands.
2. Audit — measure how much value you're actually getting from your Day AI agents and the workspace today, and surface the gap: who's missing, who needs the agents they don't have, and which skills and identities are weak.
3. Implement — translate that plan into real configuration in your Day AI workspace: the right people invited at the right roles, and every teammate's agent set up with thoughtful, role-specific skills that do real work on a schedule.

It is meant to be cloned and adapted. Nothing here is specific to one company — the planning documents are scaffolds for you to fill in, and the agents and skills know how to read your workspace and tailor everything to it.

For the pre-signup mode: nothing but this repo and Claude Code. Discovery, the first-win pilot design, and the preflight payload all work with no Day AI account at all.

To touch a live workspace, two things:

1. The Day AI MCP server, authenticated. Every workspace read and write runs through it. Setup instructions are below.
2. You must be an Owner or Admin of your Day AI workspace. Most of what the implementation side does — reading and editing other teammates' agents, creating skills for them, inviting members, changing roles — requires the Admin or Owner role. A Member can use the planning side, but the implementation side will return "requires Admin or Owner" errors. If you're not sure what role you are, run /start — it checks first.

The MCP server lives at https://day.ai/api/mcp (streamable HTTP). It authenticates over OAuth — the first time a tool is called, you'll be prompted to authorize in the browser. That authorization resolves your workspace, your user, and the agent your token belongs to; you never pass any of those by hand.

This repo already ships a .mcp.json pointing at it:

{
  "mcpServers": {
    "day-ai": { "type": "http", "url": "https://day.ai/api/mcp" }
  }
}

When you open this folder in Claude Code, you'll be asked to approve the day-ai MCP server. Approve it, then complete the OAuth flow. No Day AI account yet? Approve the server anyway and just close the OAuth login when it opens — nothing else is needed. /start detects the pre-signup state and drives the mapping work without a workspace; the connection only matters on connect day. To verify the connection and your role in one step, run:

/start

If you prefer to add it manually (or to your global config):

claude mcp add --transport http day-ai https://day.ai/api/mcp

GTM Brain runs across three planes, and it's worth keeping them straight:

day-ai/gtm-brain is the public harness source, not an enabled GitHub template. The guided setup skill creates the private team repo with the correct Git history and remotes. Once it does, the team should:

1. Keep the team repo private. The planning layer contains revenue strategy, forecasts, and candid notes about teammates that don't belong in a public repo.
2. Add your operators as collaborators. The people who actually run the harness — typically a small group: CRO, RevOps, chief of staff. They each clone the repo and work against the same main.
3. Keep it in sync like any shared repo. git pull before you start, git push when you've updated the plan, an initiative, or PEOPLE.md. The repo is how operators stay aligned on what the business is doing; Day AI Pages is how the rest of the company reads it; the workspace is where it executes.
4. Pull harness improvements (optional). Keep https://github.com/day-ai/gtm-brain.git as upstream, so new skills and agent definitions can be merged with git pull upstream main.

The bootstrap-day-ai initiative (the connected-mode default) tracks this: "the team's private repo exists and the operators can sync" is one of its success criteria, so /start will check it's actually set up.

┌─────────────────────────── PLANNING LAYER ───────────────────────────┐
│  planning/COMPANY_PLAN.md   High-level goals, forecasts, plans         │
│  planning/STRATEGY.md       CRO-level revenue strategy & direction     │
│  planning/OUTCOMES.md       Concrete, fine-grained outcomes            │
│  workspace/PEOPLE.md        Who's who in the workspace (the cast)      │
└───────────────────────────────────────────────────────────────────────┘
                                   │
                    standing intent feeds bounded efforts
                                   ▼
┌────────────────────────────── INITIATIVES ───────────────────────────┐
│  initiatives/<slug>.md      Bounded, owned, time-boxed efforts with    │
│                             verifiable success criteria + a status     │
│                             (NEW · IN_PROGRESS · PAUSED · CANCELLED ·   │
│                             SUCCEEDED). The unit of work.              │
└───────────────────────────────────────────────────────────────────────┘
                                   │
                    /start takes stock and kicks off the work
                                   ▼
┌──────────────────────── IMPLEMENTATION LAYER ────────────────────────┐
│  Audit how well you're using Day AI's agents today (the agent-value    │
│    review) and the gap between the plan and reality                    │
│  Invite the right people at the right roles                            │
│  Give each person the agents they should have, with strong identities  │
│  Deploy role-specific skills that do real work on a schedule           │
│  Sync planning docs to/from Day AI Pages                               │
└───────────────────────────────────────────────────────────────────────┘

You write (with an agent's help) what the business is trying to do. You break that into initiatives — bounded efforts with a clear, checkable definition of success and someone accountable. The harness then makes your Day AI workspace reflect the plan and drive each initiative to done — and keeps it reflecting as the plan evolves.

Initiatives vs. outcomes. An outcome (planning/OUTCOMES.md) is atomic — "draft a follow-up after a call." An initiative is the larger, owned effort an outcome serves — "get the team running on Day AI by end of Q3" — realized through many outcomes, invites, agents, and skills. The repo ships two default initiatives: map-your-gtm (leads pre-signup: map the GTM and build the payload before you connect) and bootstrap-day-ai (leads once a workspace connects: get the people in, get each person on the agents they should have, get the plan real and synced). /start picks the right one for your state. See initiatives/README.md for the file format and status lifecycle.

The point of Day AI isn't a smarter chatbot you talk to all day. It's automation: you carve slices of your job into agent-shaped job descriptions and hand them over, and the agents produce work product proactively — prep, drafts, clean records, coaching — without anyone having to ask.

That has a sharp implication this harness is built around: almost every active person should be running at least two agents. One agent is a chat. Two or more means you've actually started delegating job functions. For sellers specifically, the baseline is two:

• A CRM Data Nerd — keeps every opportunity, note, and context object correct and complete from what actually happened in conversations. Works whether you run on Day AI, HubSpot, or Salesforce. This is the agent that ends "the CRM is always out of date."
• A Coach — goes deep on every deal: patterns, blockers, what's working on other reps' deals, fluent in your pipeline and process. Preps you before meetings, drafts emails to unstick deals, follows up after calls.

/agent-audit measures how far a workspace is from that bar and hands you the path to close it. /design-agent builds the agents. The whole harness exists to make the value of Day AI's agents real and visible — and most teams are capturing a fraction of it.

A note on measuring value. The analyst confirms an agent is well-built (identity, skill craft, automation) and actually delivering — it reads each skill's real run history via manage_skills → get_history to check it's firing, producing substantive (not hollow) output, and being delivered. The one thing it still can't see is engagement depth — whether a human acts on the output — a signal the MCP doesn't expose yet; the analyst is explicit about the line between what it can and can't confirm.

Three subagents do the work. You rarely invoke them directly — the skills below orchestrate them — but they're defined in .claude/agents/:

Pre-signup (no Day AI account needed):

1.  Open this folder in Claude Code.
2.  Run  /start            → detects no workspace, drives map-your-gtm
3.  Run  /discover         → outcome interview + first-win pilot scoped, then the five gates:
                             tech stack → strategy + owners → people → privacy → fleet design
4.  Drop material in discovery/inbox/ as you go — it reads before it asks
5.  Walk out with rollouts/preflight/: your fleet, skills, pages, invites, and rollout assets

Connected (from signup day onward):

1.  Approve the `day-ai` MCP server and complete the OAuth flow.
2.  Run  /start            → detects the connection; reconciles your map against the live workspace
3.  Run  /implement preflight → applies the payload with a preview at every step, first-win first
    (or on a fresh start without a map: bootstrap-day-ai → /plan → /agent-audit)
4.  Run  /audit            → how well does the workspace deliver the plan?
5.  Run  /design-agent     → design the missing agents (e.g. a Coach for each seller)
6.  Run  /implement        → invite people, tune agents, deploy skills
7.  Run  /brain-health     → weekly: catch drift before it becomes breakage

Come back to /start whenever you sit down to work — it's the standing entrypoint that tells you where every initiative stands and what to do next, not just a first-run command. /agent-audit and /audit are two lenses: one on how well you're using Day AI, one on how well the workspace delivers your plan. Re-run them — and /implement — whenever the plan or the team changes. The plan is living; the workspace should track it.

gtm-brain/
├── README.md                 ← you are here
├── CLAUDE.md                 ← operating principles for every agent in this repo
├── .mcp.json                 ← Day AI MCP server config
├── .claude/
│   ├── agents/               ← gtm-strategist, agent-implementor, data-analyst
│   └── skills/               ← start, discover, plan, agent-audit, design-agent, audit,
│                                implement, brain-health, write-skill, sync-pages, build-app
├── initiatives/
│   ├── README.md             ← what an initiative is: schema, statuses, lifecycle
│   ├── TEMPLATE.md           ← copy this to start a new initiative
│   ├── map-your-gtm.md       ← the pre-signup default: map the GTM before you connect
│   └── bootstrap-day-ai.md   ← the connected default first-run initiative
├── discovery/
│   └── inbox/                ← drop your GTM docs, exports, and Claude assets here
├── planning/
│   ├── COMPANY_PLAN.md       ← layer 1: goals, forecasts, plans
│   ├── STRATEGY.md           ← layer 2: CRO-level strategy & direction
│   └── OUTCOMES.md           ← layer 3: concrete, fine-grained outcomes
├── workspace/
│   ├── PEOPLE.md             ← who's who: roster, operator, activation owners
│   ├── TECH_STACK.md         ← every system a customer touches; migration + call-capture posture
│   └── PRIVACY.md            ← how privacy settings work + recommended setup per persona
├── docs/
│   ├── INSTRUCTION_ARCHITECTURE.md ← where every rule lives: workspace → agent → skill → prompt
│   └── CONNECTORS.md         ← what Day AI connects to and imports from
└── rollouts/
    ├── preflight/            ← the deployable payload built pre-signup (see its README)
    ├── health/               ← binding manifest + brain-health reports
    └── <date>-<slug>/        ← audit reports, agent specs, and deploy snapshots

This harness can change your live workspace — invite people, edit your teammates' agents, deploy skills that email and Slack them. That power is the point, but it demands care:

• It previews before it writes. Every /implement run shows you exactly what it will do and waits for your go-ahead.
• It respects your teammates. Skills it writes for other people are grounded in their actual role and data, never generic filler, and never expose internal strategy notes.
• You are the Owner/Admin in the loop. The agents propose; you approve. Read what they're about to deploy before you say yes.