Claude Code V2 with a properly configured CLAUDE.md file and MCP server stack is genuinely one of the most powerful development setups available right now — and as someone who builds production AI agents for advertising workflows, I can tell you that getting the configuration right separates a frustrating toy from a reliable engineering partner. This guide walks through everything you need to know, from CLAUDE.md architecture to MCP server selection, custom commands, and multi-agent patterns that actually hold up in real work.
What Is CLAUDE.md and Why Does It Matter?
CLAUDE.md is Claude Code's project memory file — a markdown document that sits at the root of your project and gets automatically loaded into context every time you start a session. Think of it as your persistent system prompt, your onboarding document, and your style guide rolled into one. Without it, Claude Code starts every session cold. With a well-crafted one, it starts as a senior engineer who already knows your stack, your conventions, your constraints, and your goals.
A common question in the r/ClaudeAI community is around how much to put in CLAUDE.md versus how much to handle through prompting in session. The answer practitioners have landed on: put anything you'd need to re-explain more than once into CLAUDE.md. Anything you'd say once in a session stays in the session. That mental model keeps the file lean and genuinely useful.
The Anatomy of a Production CLAUDE.md
A production CLAUDE.md isn't a wall of text — it's structured information Claude can parse quickly. Here's the architecture I use across projects:
Project Overview — One paragraph on what this codebase does and who it serves
Directory Structure — A brief tree or narrative explaining where things live
Coding Conventions — Formatting rules, naming conventions, patterns to use or avoid
Testing Requirements — What test coverage means here, frameworks used, how to run tests
Deployment Context — Where this runs, environment variables, secrets handling
Current Sprint / Active Context — What you're working on right now (update this weekly)
Custom Commands Reference — A list of slash commands available in this project
Key Insight: The "Current Sprint" section is the most underused element of CLAUDE.md. Updating a three-sentence summary of your active work takes 60 seconds and eliminates the 5-10 minutes of re-orientation that otherwise happens at the start of every session. Over a week, that's 30+ minutes returned.
CLAUDE.md Template for AI Agent Projects
For projects like Buddy (my open-source Google Ads agent), the CLAUDE.md needs extra sections that most tutorials skip:
API Rate Limits & Cost Constraints — Claude needs to know if token costs matter for the design choices
Agent Boundaries — What this agent is and isn't supposed to do autonomously
Error Handling Philosophy — Fail loudly vs. graceful degradation vs. retry logic preferences
Human-in-the-Loop Triggers — Explicit list of actions that require human approval before execution
Common Mistake: Writing CLAUDE.md for what your project will eventually be rather than what it is today. I've seen files with 800 words of aspirational architecture that don't reflect a single line of actual code. Claude will try to honor those instructions and diverge from your real codebase. Keep it honest — update it as the project evolves.
MCP Servers: What They Are and Which Ones Actually Matter
Model Context Protocol (MCP) servers are external processes that Claude Code can talk to, giving it capabilities beyond text generation. As practitioners often discuss in the r/ClaudeAI community, MCP servers extend Claude's capabilities exponentially — but the actual value depends entirely on which servers you configure and how you configure them.
Think of MCP servers as Claude's hands. Without them, it can think and write. With them, it can read files, query databases, browse documentation, run searches, call APIs, and manipulate browser state.
The Core MCP Stack Worth Installing
MCP Server
What It Does
Best For
Priority
Context7
Pulls live documentation for libraries & frameworks
Any project using actively-updated dependencies
Essential
Filesystem
Read/write files outside the working directory
Multi-repo work, config management
Essential
Brave Search
Real-time web search from within Claude Code
Research, error diagnosis, checking current APIs
High
GitHub
PR creation, issue management, repo operations
Teams, open source projects
High
Puppeteer / Playwright
Browser automation & scraping
Testing, data collection, UI validation
Medium
PostgreSQL / SQLite
Direct database querying
Data-heavy applications
Project-specific
Context7: The One MCP Server You Should Install First
Context7 deserves special attention. One of the persistent frustrations with AI coding assistants is that their training data has a cutoff date — and libraries like the Google Ads API, LangChain, or even Next.js change fast enough that hallucinated method signatures and deprecated patterns are a real problem.
Context7 solves this by fetching up-to-date documentation dynamically when Claude needs it. When you're working on something like a Google Ads API integration and you ask Claude to write a query using the latest campaign performance metrics, Context7 pulls the actual current docs rather than relying on potentially stale training data. In my workflow, this has reduced API-related debugging time by a meaningful margin — I'd estimate 40-60% fewer "why isn't this method working" cycles on dependencies that change quarterly.
Best Practice: After installing Context7, add a line to your CLAUDE.md that explicitly instructs Claude to use it: "Before implementing any third-party library functionality, use Context7 to fetch current documentation rather than relying on training data." This creates a consistent retrieval habit across all sessions.
Custom Commands: Building Your Own Claude Code Toolkit
Custom slash commands are one of the most underutilized features in Claude Code. They let you define repeatable workflows as named commands that Claude executes consistently — every time, without drift.
How Custom Commands Work
Commands live in .claude/commands/ at your project root (or ~/.claude/commands/ for global commands). Each command is a markdown file where the filename becomes the command name and the content is the instruction set Claude follows.
For example, a file at .claude/commands/review-pr.md becomes /project:review-pr in your Claude Code session.
Commands That Deliver Real Workflow Value
Here are the custom commands I actually use in production:
/project:test-and-fix — Runs the test suite, reads the output, identifies failures, attempts fixes, re-runs. Loops up to 3 times before surfacing to human review.
/project:api-audit — Reviews all external API calls in the codebase for error handling, rate limit compliance, and authentication patterns
/project:changelog — Reads recent git commits and drafts a structured changelog entry following our format
/project:cost-estimate — For AI agent projects specifically: analyzes the code and estimates token consumption per operation based on current pricing
Key Insight: The value of custom commands isn't just convenience — it's consistency. When you have a /project:test-and-fix command, every developer on the team (human or AI) follows the same process. This is especially powerful in agentic workflows where you want predictable, auditable behavior rather than improvised solutions.
Command Design Principles
Be specific about outputs — Don't just say "review the code," say "produce a bullet list of issues organized by severity: Critical, High, Medium, Low"
Define stopping conditions — Tell Claude when to stop and ask for human input rather than continuing autonomously
Include context references — Good commands reference the CLAUDE.md conventions: "Follow the error handling patterns defined in CLAUDE.md"
Version your commands — Keep commands in version control. They're part of your engineering infrastructure now.
Multi-Agent Patterns with Claude Code
Once you have CLAUDE.md and MCP servers running, the next level is orchestrating multiple Claude Code instances as specialized agents that hand off work to each other. This is where things get genuinely powerful for complex projects.
The Orchestrator-Subagent Pattern
The most reliable pattern I've found is one orchestrator instance that plans and delegates, paired with specialized subagents that execute:
Orchestrator — Receives the high-level goal, breaks it into tasks, assigns to subagents, validates outputs
Researcher Agent — Uses Brave Search and Context7 MCP servers to gather information
Builder Agent — Writes implementation code, has filesystem and GitHub access
Tester Agent — Runs tests, reads results, reports back to orchestrator
In the context of Buddy (the Google Ads agent), this pattern runs as: a planning agent that interprets campaign performance data and decides what optimizations to propose, an implementation agent that writes the API calls, and a validation agent that checks the proposed changes against account rules before anything goes near a human approval queue.
Best Practice: Give each subagent a separate CLAUDE.md or append agent-specific instructions to the shared one under clearly labeled headers. An agent that only reviews code should know it has no write permissions — and that constraint should live in its context, not just in your workflow design.
Where Multi-Agent Setups Break Down
Common Mistake: Building multi-agent systems without explicit handoff formats. When your orchestrator passes a task to a builder agent, the output format needs to be structured and predictable — not "here's what I found, good luck." Define JSON schemas or markdown templates for inter-agent communication from the start, not as an afterthought when things start breaking.
Context window management is the other failure mode. Each agent in a long chain accumulates context, and if you're not actively managing what gets passed between agents, you'll hit limits or start getting degraded outputs. The practical fix: summarize outputs before passing them forward. Don't pass 2,000 tokens of test output to the next agent — pass a 200-token structured summary with the full output stored to a file the agent can reference if needed.
Connecting This to Marketing & Advertising Workflows
For the advertisers and marketing teams reading this, Claude Code V2 with this stack isn't just a developer tool — it's infrastructure for building the custom AI tooling your campaigns actually need.
The generic AI tools on the market are built for median use cases. Your Google Ads account structure, your creative testing methodology, your attribution model — none of that is median. When I built Buddy, the core problem was that no off-the-shelf tool understood our specific campaign hierarchy, our budget rules, or the way we structured ad groups for different match type strategies.
With Claude Code configured properly, a marketing technologist or even a technical account manager can build:
Custom reporting agents that pull data from multiple sources and format it the way your team actually reads it
Bid adjustment tools that encode your specific rules rather than a platform's generic recommendations
Creative analysis pipelines that evaluate ad copy against your brand guidelines, not generic best practices
Campaign audit tools that check for your specific compliance requirements and account structure rules
The CLAUDE.md for a marketing-focused project should include your attribution model, your KPI hierarchy (what matters most — ROAS, CPA, impression share?), your account structure conventions, and the platform API documentation references your agents will need. MCP servers like the Google Ads API integration or a custom reporting database connector become your agent's data access layer.
What to Do Next
If you're starting from zero or trying to level up an existing Claude Code setup, here's the sequence that works:
Create your CLAUDE.md today. Even a rough draft covering your stack, conventions, and current focus is dramatically better than nothing. Block 20 minutes, write it, commit it. Refine it next week.
Install Context7 as your first MCP server. Configure it, add the retrieval instruction to your CLAUDE.md, and spend one session testing it on a real library you're working with. See the difference in documentation accuracy firsthand.
Build three custom commands for your most repeated workflows. Look at what you re-explain to Claude most often in sessions — that's your command backlog. Start with those three.
Design one multi-agent workflow before automating it. Map the orchestrator and subagent roles on paper (or a doc), define the handoff formats, then implement. The planning phase catches 80% of the problems that kill multi-agent projects.
Version control all of it. CLAUDE.md, your .claude/commands/ directory, your MCP configuration — treat this as engineering infrastructure because it is. It should be in your repo, reviewed like code, and evolved deliberately.
Claude Code V2 with a solid CLAUDE.md, a well-chosen MCP stack, and purpose-built custom commands is a genuinely different experience from vanilla Claude Code — more like working with a configured system than prompting a chatbot. The setup investment is real, but the compounding returns across every session after that make it one of the highest-leverage things you can do if AI-assisted development is part of your work.
AI Disclosure: This article was generated with AI assistance based on a community discussion on Reddit r/ClaudeAI. Expert analysis and practitioner perspective by John Williams, Founder, AHMEEGO · Google Ads Practitioner with $350M+ in managed Google Ads spend. AI was used to draft and structure the content; all strategic recommendations reflect real campaign experience.
