CLAUDE.md for GTM Teams: How We Configure Claude Code to Run Our Agency

CLAUDE.md is the configuration file that tells Claude Code who it is, what it is working on, and how it should behave. It sits in the root of your project, gets read at the start of every session, and is the difference between Claude acting like a helpful-but-generic coding assistant and Claude acting like a specialized agent that understands your operation.

For a GTM agency, this distinction is everything. We do not want Claude Code to be smart in general. We want it to be smart about our specific workflows, our specific file structure, our specific tools, and the specific ways things can go wrong in our context.

Here is how we structure ours, and why each section exists.

---

Why CLAUDE.md Matters More Than Prompting

Most people use Claude Code by prompting it in each session: "here is what I need, here is some context, please help." This works. But it does not scale.

The problem with session-level prompting for an agency is consistency. Different team members give Claude different context. The same person phrases things differently on different days. Claude has no memory of what happened in previous sessions, so every session starts from scratch. The result is an assistant that is capable but unpredictable -- you get good outputs when you ask the right way, mediocre outputs when you do not.

CLAUDE.md solves this by moving critical context out of the prompt and into the project itself. It is version-controlled, shared across the team, and always present. Claude reads it before anything else.

According to Anthropic's documentation, CLAUDE.md files are automatically loaded into Claude's context for every session in a project directory. Multiple CLAUDE.md files can exist in subdirectories for different parts of a project, allowing fine-grained configuration at the component level.

---

Section 1: Identity

The first section tells Claude what kind of agent it is. This is not vanity -- it shapes how Claude interprets ambiguous instructions throughout the session.

A generic Claude Code agent might interpret "clean up this lead list" as a formatting task. An agent that knows it is operating as a GTM orchestration layer will interpret the same phrase as: check for duplicates, verify domains, flag contacts that do not match the ICP, and update statuses in the database.

What to include:

• One-paragraph description of the agent's role
• The problem it exists to solve
• What it should and should not do itself vs. delegate to scripts

Sanitized example:

## Identity

You are the GTM Operations Agent for [Agency Name]. Your role is to
orchestrate the agency's sales pipeline -- from lead sourcing through
campaign delivery and reporting.

You operate in a 3-layer architecture:
Directives tell you what to do (written SOPs in /directives/)
You make decisions and sequence the work
Execution scripts in /execution/ do the actual data processing

You do not scrape websites manually or call APIs directly when a script
exists. You read the directive, identify the right tool, run it, interpret
the output, and handle edge cases.

The identity section is short, but it anchors every decision Claude makes for the rest of the session.

---

Section 2: Architecture -- Separating Directives, Orchestration, and Execution

This is the most important structural decision in our CLAUDE.md, and it is the one most people skip.

The core insight: language models are probabilistic. Business processes need to be deterministic. If you let Claude write code, execute it, interpret the results, and take the next action all in one unstructured flow, errors compound. One bad assumption early in the chain produces compounding garbage downstream.

The three-layer architecture breaks this apart:

Layer 1 -- Directives are written SOPs in a /directives/ folder. They define goals, inputs, the tools to use, expected outputs, and known edge cases. Written in plain English, like instructions for a thoughtful new hire. Layer 2 -- Orchestration is Claude's job. Read the directive, sequence the steps, call the right execution scripts, handle errors, ask for clarification when needed. Layer 3 -- Execution is Python scripts in an /execution/ folder. These are deterministic, tested, and reliable. They handle API calls, database operations, and data processing. They do not make judgment calls -- that is Claude's job. Sanitized example CLAUDE.md section:

## Architecture

Layer 1: Directives (/directives/)
SOPs organized by GTM category: lead_sourcing, enrichment, scoring,
copywriting, etc. Each directive defines the goal, required inputs,
which script to run, expected output format, and known edge cases.
Read the relevant directive before starting any workflow.

Layer 2: Orchestration (You)
Your job: read directives, sequence steps, call execution scripts,
interpret outputs, handle errors, ask for human approval when needed.
You are the decision layer, not the execution layer.

Layer 3: Execution (/execution/)
Deterministic Python scripts, one concern per file. If the directive
says "run execution/enrichment/enrich.py", run that script. Do not
rewrite it unless it is broken.

This separation is what makes the system reliable. Scripts can be tested independently. Directives can be updated without touching code. Claude's decision-making can be improved without breaking existing automations.

---

Section 3: File Organization

Claude Code needs to know where things live. Without explicit file organization instructions, Claude will make reasonable guesses -- which means different guesses in different sessions, which means inconsistency.

The CLAUDE.md file organization section should define:

• Where deliverables go vs. where intermediates go
• The naming conventions for new files
• Which directories are off-limits for writes
• Which files require backup before modification

Sanitized example:

## File Organization

/directives/ -- SOPs (living documents, update when you learn new things)
/execution/ -- Python scripts (one file per concern, mirroring directive structure)
/.tmp/ -- Temporary processing files (never commit, regenerate as needed)
/knowledge/ -- Reference context: client notes, research, configurations
Key rule: Local files are for processing only. Client-facing deliverables
live in Google Sheets, Google Slides, or other cloud tools the client can access.
Everything in .tmp/ is expendable.

---

Section 4: Operating Principles

Operating principles are the behavioral rules that govern how Claude approaches ambiguous situations. Without them, Claude defaults to its training -- which produces capable but inconsistent behavior.

The principles that matter most for a GTM operation:

Check for tools first. Before writing a new script, check whether one already exists. A GTM stack accumulates scripts over time. Redundant scripts doing the same thing from different angles are a maintenance nightmare. Self-anneal when things break. When a script fails, Claude should: read the error, fix it, test the fix, and update the directive with what it learned. This is the difference between an assistant and a system -- the system improves itself over time. Update directives as you learn. Directives are not static documents. When Claude discovers an API has rate limits, or a data source has quality issues, or a workflow has an edge case -- the directive gets updated in the same session. Sanitized example:

## Operating Principles

Check for tools first. Before writing a script, check the matching
   /execution/ subfolder. Only create new scripts if nothing exists.

Self-anneal when things break.
   - Read the error and stack trace
   - Fix the script
   - Test it again (unless it uses paid credits -- then ask first)
   - Update the directive with what you learned

Update directives as you learn.
   When you discover something new -- API limits, edge cases, better approaches --
   append a changelog entry to the relevant directive. Do not overwrite existing
   content unless it is wrong.

---

Section 5: Safety Guardrails

Safety guardrails are the non-negotiable rules. They exist because the cost of getting certain things wrong is asymmetric -- a mistake on a paid API call, a destructive database operation, or an accidental credential exposure can cause real damage that is hard to undo.

The guardrails we use:

## Safety Guardrails

These are non-negotiable:

Confirm before costly API calls. Always ask for human approval
   before any API call estimated to cost more than $5.

Never modify credentials without approval. Do not touch, overwrite,
   or delete API keys or tokens without explicit permission.

Never expose secrets. Credentials stay in .env only. Never hardcode
   them in scripts or print them to output.

Log directive modifications. When you update a directive, append a
   changelog entry at the bottom: date + what changed + why.

The third guardrail -- never expose secrets -- sounds obvious but is surprisingly easy to violate. Claude might include a real API key in a code example if it saw one earlier in context. Explicit rules prevent this.

---

How Skills Fit In

Beyond CLAUDE.md, we use a Skills system for complex, reusable workflows. A Skill is a subdirectory with a SKILL.md file that Claude reads when you invoke it. Think of CLAUDE.md as the general operating manual and Skills as specialized runbooks for specific tasks.

A sanitized example Skill structure for a proposal generator:

skills/
  proposal-generator/
    SKILL.md              # The instructions for this skill
    assets/
      template.html       # The proposal HTML template
    references/
      design-system.md    # Brand guidelines

The SKILL.md for a proposal generator would define: what inputs it needs (client name, services, pricing), what it produces (a formatted HTML file ready for PDF export), and the step-by-step process for generating it. When a teammate says "generate a proposal for this client," Claude reads the Skill and follows the process exactly -- not its own interpretation of what a proposal should look like.

Skills are useful for any workflow that:

• Has a specific format or template requirement
• Gets used repeatedly across different clients or projects
• Requires a sequence of steps that should always happen in the same order

---

The Commit Message Format -- An Underrated Section

One section of CLAUDE.md that most teams skip but we find extremely valuable: a defined commit message format.

When multiple people (and an AI agent) are committing to the same repo, the commit history becomes unreadable fast. Defining the format in CLAUDE.md means Claude follows it automatically, and it serves as a reminder for humans too.

Sanitized example:

## Git Commit Messages

Format:
[category] Short summary under 72 chars

WHAT CHANGED:
path/to/file.py: Specific description of what changed
path/to/other.md: What was updated and why

WHY:
Plain English explanation of the goal.


Categories: [setup] [directive] [execution] [fix] [feature] [data] [infra] [docs]

A well-structured commit history means any team member -- or Claude in a future session -- can understand what happened and why without reading every diff.

---

The Result: Consistent Behavior Across Sessions and Teammates

The practical outcome of a well-written CLAUDE.md: Claude Code behaves consistently regardless of who is in the session, what they asked for, or how they phrased it. The agent has a stable identity, knows where things live, follows defined processes, and applies the same safety rules every time.

For a growing agency where multiple people are working in the same codebase, this consistency is what makes Claude Code a team tool rather than a personal tool. The CLAUDE.md is the shared contract.

We pair this with individual profile files for each team member -- a short Markdown file with their name, role, and focus areas. Claude references these in session summaries and commit messages so outputs are personalized to the person doing the work while the core behavior stays consistent.

For more on the agentic infrastructure that plugs into this configuration, see agentic workflows explained. If you want to see what this looks like built as a service, the sales automation page goes into how we deliver this for clients.

---

What to Put In Yours (A Starting Template)

If you are building a CLAUDE.md for a GTM operation and want a starting point:

Minimum viable CLAUDE.md:

1. Identity paragraph -- what this agent does and what it does not do
2. File structure map -- where to find and write things
3. Active integrations list -- tools, APIs, and credentials it can use
4. Three operating principles -- the behavioral rules you care most about
5. Two safety guardrails -- the things that should never happen automatically

Start there. Add sections as you discover gaps. The CLAUDE.md you have in week four will look nothing like the one you wrote on day one -- and that is exactly right. The file should grow with your understanding of your own operation.

What we have learned building this over the past year: the value is not in any individual section. The value is in having a shared document that the whole team, including the AI, is reading from. That shared context is what makes the system coherent.