Claude Code CLAUDE.md Template for GTM Teams
The sections that matter, the examples that calibrate the model, the rules that prevent drift.
What CLAUDE.md Does
A CLAUDE.md is a markdown file at the root of your project. Claude Code loads it automatically at the start of every session in that directory. The contents become persistent context the model uses across every prompt in the session.
For GTM teams, this matters because the model needs to know your ICP, your voice, your conventions, and your guardrails to produce useful output. Without CLAUDE.md, you re-explain these every prompt. With it, your team gets consistent output from the agent regardless of who triggered the session.
For broader context on Claude Code and how skills, hooks, and CLAUDE.md fit together, see Claude Code Skills for GTM Engineers.
The Template Structure
Six sections cover what most GTM teams need.
Section 1: Company Context (10-15 lines)
One paragraph on what your company does. One paragraph on your product. One paragraph on your market position.
Example:
"Acme is a B2B SaaS platform that helps mid-market RevOps teams unify their CRM, sequencer, and warehouse data into one operational dashboard. Founded 2022. Series B, $35M raised. 65 employees as of June 2026."
Keep it tight. The model uses this to ground every output in your company's reality. Long marketing copy isn't useful here. Specific facts are.
Section 2: ICP Definition (30-50 lines)
This section gets the most space and the most attention. The ICP rules should be specific enough that the model can score an account against them without ambiguity.
Structure:
Primary ICP. Industry list, employee count range, revenue range, geography, funding stage, tech stack signals. Specific numbers, not "mid-market".
Secondary ICP. The expansion segment. Same structure as primary.
Disqualifiers. What automatically rules out an account. "Less than 50 employees." "Not headquartered in North America or EMEA." "Uses Marketo (we don't have a Marketo integration)."
Scoring weights. If you score accounts, the weights for each criterion. Employee count: 25 points. Industry match: 20 points. Funding recency: 15 points. Etc.
Buyer personas. The three to five titles you sell to. Their priorities, their objections, their typical buying timeline.
For the framework underneath this section, see the ICP definition framework.
Section 3: Voice and Style (15-30 lines)
This is where you keep AI output from sounding like AI output.
Structure:
Tone. Two or three sentences describing how your team writes. "Direct, occasionally wry, never breathless. We use contractions. We start sentences with verbs when it tightens the rhythm."
Sentence length. "Vary dramatically. Short punches. Then longer context. Avoid uniform paragraph lengths."
Banned words and phrases. A bulleted list of words your team never wants the agent to produce. The standard AI-tell list works as a starting point (lev*rage, ut*lize, r*bust, s*amless, h*listic, and similar puffery words). Your team's voice probably has a few more specific to your category.
Banned patterns. Explicit rules on phrasing the agent should never produce. No reframing sentences. No em-dashes. No opener with "So," or "Meanwhile,".
Two example outputs. Two short examples (a cold email opener, an internal Slack message) that demonstrate the voice. The model uses these as calibration anchors.
Section 4: Glossary (10-20 lines)
Terms your team uses with specific meanings. The model needs these definitions to use the terms correctly.
Examples:
ICP: Our primary or secondary segment as defined in Section 2. Never use "ICP" loosely to mean any prospect.
Tier A: Accounts scoring 70+ on our scoring rubric. Get personalized sequences.
Pipeline review: The Monday meeting where we review open opps. Not a generic CRM review.
Brief: A one-page account research document. Not a generic summary.
Add 5 to 15 terms specific to your team. Skip the generic SaaS jargon the model already understands.
Section 5: Workflow Conventions (10-25 lines)
How your team operates that the model should respect.
Examples:
"All outbound drafts are staged in the sequencer with status paused. A human approves and activates."
"CRM writes include provenance: ai_source = claude-code, ai_updated_at = run timestamp."
"Account research output goes to Notion (database: Account Research) and HubSpot (custom property: ai_research_summary)."
"Reply triage classifications use the five buckets in skills/reply-triage. No additional classifications."
"Slack alerts only for Tier A accounts and only between 7 AM and 6 PM PT."
Two or three short rules per workflow keep the agent operating consistently across sessions.
Section 6: Guardrails (10-20 lines)
The hard rules. Things the agent should never do, regardless of how a prompt is worded.
Examples:
"Never send email directly. Always stage drafts for human approval."
"Never write to a CRM property not on the allow list in conventions/allowed_fields.json."
"Never call paid enrichment vendors on an account researched within the last 30 days."
"Never include customer PII (names, emails, phones) in any output saved outside the CRM."
"Never delete CRM records or contacts."
These guardrails are the prompt-level layer. Hooks (deterministic Python scripts that block bad operations) are the runtime-level layer. Both matter. See the AI SDR guardrails guide for the three-layer model.
What to Leave Out
Three categories of things don't belong in CLAUDE.md.
Customer-specific data. Belongs in your CRM, accessed at runtime through MCP. Putting customer names or contact data in CLAUDE.md means it gets sent to the LLM provider with every call.
Long-form marketing copy. Your website's "About" page doesn't help the model do GTM work. Keep company context tight.
Workflow logic that should be in a skill. If you find yourself documenting step-by-step instructions for a specific workflow in CLAUDE.md, that's a sign it should be a separate skill in ~/.claude/skills/ instead.
Maintaining the File
The CLAUDE.md should evolve as your team's understanding evolves. Three patterns help.
Quarterly review. One person owns the file. They read it once a quarter, prune stale rules, add new conventions, and PR the changes.
Drift detection. When you notice the agent producing output that doesn't match your team's voice, that's a signal that CLAUDE.md needs an update. Don't fix it by rewriting the bad output. Fix it in the file.
New hire onboarding. When a new GTM Engineer joins, the CLAUDE.md doubles as documentation of your team's GTM operations. If they read it and have follow-up questions, those questions point at sections that need expansion.
For the skills, hooks, and broader Claude Code architecture this file sits inside, see Claude Code Skills for GTM Engineers and the sales agent guide.
Authoritative References
For the Claude Code CLAUDE.md file specification and loading behavior, see Anthropic's Claude Code documentation.
Frequently Asked Questions
What is a CLAUDE.md file?
A CLAUDE.md is a project-level instruction file Claude Code loads automatically at the start of every session in that project directory. It's where you put persistent context the agent should remember across runs: company info, ICP rules, voice guidelines, glossary terms, banned phrases, and conventions. Without it, you re-explain context every prompt. With it, the agent starts every session already calibrated to your team.
How long should a GTM team's CLAUDE.md be?
Between 80 and 250 lines for most teams. Shorter than 80 means the agent doesn't have enough context to produce consistent output. Longer than 250 means the model is loading lots of context every session and you're paying for tokens that aren't pulling weight. The sweet spot for most GTM teams is around 120 to 180 lines covering company, ICP, voice, glossary, and key conventions.
Should the CLAUDE.md include sensitive customer data?
No. The CLAUDE.md gets loaded into context for every model call, which means it's processed by the LLM provider. Don't put customer lists, individual prospect data, or PII in it. Keep it to company-level rules, ICP definitions, and stylistic guidance. Customer-specific data should be pulled at runtime through MCP servers, not baked into the project context.
How do I keep CLAUDE.md from drifting as my team grows?
Treat it like code. Version control it. Require PRs for changes. Review it quarterly. Most teams that ship Claude Code well have a designated CLAUDE.md owner (usually the GTM Engineer who shipped the first workflow) who reviews and accepts changes. Without ownership and review, the file accumulates contradictions and becomes less useful over time.
Can different team members have different CLAUDE.md files?
Yes. The project-level CLAUDE.md is shared across the team. Each user can also have a global CLAUDE.md (in ~/.claude/CLAUDE.md) that adds personal preferences without affecting shared output. The pattern that works: team-shared file for ICP, voice, and conventions. Personal file for individual workflow shortcuts and personal style preferences.
Source: State of GTM Engineering Report 2026 (n=228). Salary data combines survey responses from 228 GTM Engineers across 32 countries with analysis of 3,342 job postings.