CMOs as Builders: The CLAUDE.md Blueprint

In Post 7, I showed you how to move your AI work off your laptop and into your organization. GitHub as a shared filing cabinet. The start-build-ship cycle. A human-in-the-loop workflow where Claude proposes, you decide, and the system executes.

I kept pointing at one file and never opening it. CLAUDE.md. The file Post 7 said “makes everything you’ve built consistent, scalable, and teachable.”

This is that file. And it’s the last piece, because it’s the one that holds all the other pieces together.

Subscribe to get every post in this series delivered to your inbox: kevinkerner.substack.com

The Series: CMOs as Builders

1 -- Why CMOs Who Build Will Win -- The case for moving from AI user to AI builder, and why stepping out of the chat window changes everything.

2 -- Your First 30 Minutes with Claude Code -- How to install Claude Code, get oriented, and build your first real output.

3 -- How to Give Claude Code Its Orders -- The difference between a prompt and a directive, and how to communicate so Claude builds what you actually want.

4 -- Stop Losing Your Work: Sessions and Context -- Why Claude forgets everything when you close a session, and the simple habits that make your work carry forward.

5 -- Skills, Efficiency and Model Switching -- Haiku, Sonnet, Opus: what each model is for, when to use which one, and how the wrong choice cost me $75 in a single session.

6 -- Beyond the Terminal: MCP, APIs, and the Tools That Connect Everything -- The infrastructure layer that turns Claude from a smart assistant into the brain of an automated system.

7 -- From Terminal to Teammate -- How to bring your team into the systems you’ve built without losing control of what you’ve created.

8 -- The CLAUDE.md Blueprint (you are here) -- The one document that ties everything together: your operating manual for building with AI at scale.

What you’re about to understand -- why most AI systems quietly depend on one person, and the single file that fixes it:

You’ve built real things now. Maybe a few of them. They live in GitHub, your team has access, and the work moves. But somewhere in the back of your mind you know that if you stepped away for a month, the quality would slowly drift. The rules that make your systems good live in your head, and your head doesn’t scale. This is the gap CLAUDE.md closes.

By the end of this post you’ll know how to:

• Write a CLAUDE.md that turns your judgment into standing instructions - the rules you keep re-explaining, written down once so Claude follows them every session, for everyone.

• Recognize why this file ties the whole series together - it’s the operating manual that makes the terminal, the skills, the connections, and the team workflow behave consistently.

• Set the guardrails that keep a shared system safe - who approves what, what can’t be changed without review, and the automatic check that catches a broken change before it ships.

• Know when you’ve built enough governance and when you’re overbuilding - so you protect what matters without strangling a system that’s still just you and two skills.

Why this matters for you as a CMO:

The systems most teams build have a hidden single point of failure, and it’s the person who built them. Your standards live in your feedback on drafts, your taste, your gut. CLAUDE.md is how you take that out of your head and put it into the system, where it applies on its own. That’s the difference between a setup you have to babysit and one your team can actually own.

Time to read: 9 minutes What you need: Post 7, ideally the whole series. Something you’ve already built and want to make durable.

In one sentence. CLAUDE.md is a plain text file that Claude Code reads automatically at the start of every session, so it knows your project’s rules without you re-explaining them.

That’s the whole idea. You write your standing instructions once. Claude reads them every time. You stop repeating yourself, and so does everyone else who uses the system.

Back in Post 3, the orders were for the moment. Do this, then that, here’s the format. CLAUDE.md is the version that sticks. It’s the standing orders that apply to every session until you change them.

Most AI systems a marketing team builds have a hidden single point of failure, and it’s the person who built them. Your standards live in your head, your taste, your feedback on drafts. CLAUDE.md is how you take that out of your head and put it into the system, where it applies on its own.

Think about how you’d onboard a new agency. You don’t re-explain your brand voice in every meeting. You write it down once, everyone reads it, and the work stays on-brand because the expectations are written instead of remembered. CLAUDE.md is that document, except your AI reads it instead of a strategist.

A good one answers four questions:

• What is this? A line or two of context, so Claude understands what it’s working on.

• What are the rules? The things to always do and the things to never do.

• Where do things live? The key files and folders, and what each is for.

• What’s the current state? What’s done, what’s in progress, what to leave alone.

Here’s a real one. This is a portion of the actual CLAUDE.md that runs the system Mighty & True uses to manage its AI skills across the whole team. I trimmed it, but every line is real:

# Company Claude Skills
This repository is the source of truth for our shared
Claude skills and Claude Code plugins.
## Rules
- Use pull requests for every change. Do not push directly to main.
- Keep shared behavior in the core, engineering, or marketing plugins.
- Run the validation script before finishing.
- Stage files by name. Do not use the "add everything" shortcut.
- Update the catalog whenever you add, move, or rename a skill.

Look at what those rules actually are. None of them are clever. Every one is a mistake somebody made, written down so it never happens twice. “Stage files by name” is there because the lazy shortcut, “add everything,” is how a file with a password in it ends up somewhere it shouldn’t. “Run the validation script before finishing” is there because somebody once shipped something broken and we didn’t catch it until a client did. “Do not push directly to main” is there because the live system should never change without a second set of eyes.

That’s the real value of the file. Every line is a lesson you only have to learn once. Your judgment, the stuff that usually lives in feedback on a draft, goes here instead, where the next session and the next hire inherit it for free.

Here’s a blueprint you can fill in today, for one thing you’ve already built:

# [Project name]
[One line: what this is and who it's for]
## What this is
[Two or three sentences of context]
## Rules
- [Things to always do]
- [Things to never do]
## Where things live
- [Key files and folders, and what each is for]
## Current state
- [What's done, what's in progress, what to leave alone]

Fill that in and you’ve done the most important thing in this entire series. You’ve taken something that worked because you understood it, and made it work because it’s written down.

And if writing the rules from scratch feels like a lot, you don't have to do it alone. Claude has a skill creator, built right into Claude.ai, that takes a plain description of a workflow and writes the instructions for you. It's the same move as the CLAUDE.md, one level up. You describe what good looks like, and it drafts the rules. A good way to go from one written file to a small library of them, which is exactly what Post 5 was pointing at when we talked about skills.

CLAUDE.md tells everyone the rules. It doesn’t stop anyone from ignoring them.

Post 7 got your team into the repo. The moment that happens, a new risk shows up. A well-meaning teammate pushes a change that breaks the thing everyone now depends on. Not out of carelessness, just because they didn’t know what they didn’t know. The rules were in the CLAUDE.md. Nothing made them follow it.

So the CLAUDE.md is half the answer. It’s the standards. The other half is the small set of guardrails that make the standards stick, even when someone’s in a hurry. Especially then.

You already know pull requests from Post 7, where a teammate reviews a change before it goes live. The guardrails sit on top of that, and they’re worth your attention because they’re the part most CMOs skip.

Who reviews what. GitHub has a file called CODEOWNERS, and all it does is name who has to approve changes to which parts of the system. Marketing changes get reviewed by the marketing lead. Engineering changes get reviewed by engineering. You’d never let the design team sign off on legal copy. This is the same instinct, written into the system so it happens on its own. The right person looks at the thing they actually understand, every time, without anyone having to remember to ask them.

What can’t be skipped. GitHub lets you turn on a setting called branch protection. It’s a rule that stops anyone, including you, from pushing a change straight to the live system without going through review. This is the one leaders underrate, and it’s the most important. The point isn’t that it controls your team. The point is that it controls you. The person most able to skip the process is the person who set it up, and the person most likely to skip it is whoever’s having a bad Tuesday and just wants the thing fixed now. Branch protection is you protecting the company from your own worst impulse.

What catches the mistakes nobody saw. The last guardrail is an automatic check that runs on every proposed change and blocks it if something’s broken. In our system, a small script runs the moment anyone proposes a change and confirms nothing is broken before a human even looks at it. If the check fails, the change can’t go live, and the person who proposed it sees exactly what went wrong. It’s a proofreading pass that never gets tired and never gets talked into letting one slide.

Put those together and you have the operating model: one shared home for the system, every change proposed instead of forced, the right owner reviewing it, and an automatic check standing guard the whole time. It sounds like a lot of machinery. It’s the same approval discipline you already trust with everything that leaves your building. You’re pointing it at a new kind of asset, one that happens to run your marketing.

Here’s the honest part, because the worst thing I could do is talk you into building a four-lane highway for a footpath.

Most of this guardrail layer earns its place under two conditions: more than one person touches the system, or a broken change would actually cost you something. If neither is true yet, you don’t need it yet.

There’s a ladder here, and you climb it only when the rung you’re on starts to hurt.

If it’s just you and a couple of skills, a good CLAUDE.md and your files saved somewhere safe is the whole game. Reaching past that is wasted effort.

When a second person needs in, you climb to a shared repo, which is where Post 7 left you.

When a bad change would cost real money or real trust, or when enough people are involved that “just be careful” stops being a plan, you add the guardrails from this post.

Don’t build the governed version on day one. Build the CLAUDE.md. Save your work. Add owners and protection and checks when the cost of a mistake, or the number of hands on the system, makes them worth it. Knowing this layer exists changes how you build long before you need all of it, because you’ll build things that are ready to climb the ladder instead of things you have to tear down and start over.

Eight posts ago I made a claim. CMOs who build will win.

Everything since has been the foundation under that claim. Opening a terminal you’d never touched. Learning to give Claude clear orders. Keeping your work across sessions. Choosing the right model for the job. Connecting Claude to the rest of your stack. Bringing your team into what you built. And now the file that holds all of it in one place.

The thread running through every one of those posts was a single idea. A conversation ends. A system persists. The chat window closes and takes your work with it. A system keeps working when you’re not in the room, gets better every time someone improves it, and hands every new hire the intelligence it’s accumulated.

The CMOs who get durable leverage from AI aren’t the ones with the best prompts. They’re the ones who turned their own judgment into something their team can run without them. The CLAUDE.md is where that judgment lives. The guardrails are what keep it safe once other people start building alongside you.

You don’t need all of it tomorrow. You need to start. Open one thing you’ve built, write down the rules you keep re-explaining, and save it as CLAUDE.md. That’s the first line of your operating manual. Everything else in this series was just teaching you how to read it.

This is what we do at Mighty & True.

We’re a B2B growth advisory that builds AI-powered systems for growth-stage CMOs. The web systems, the GTM plays, the content and media programs you’ve read about across this series, those are our systems, and we build the same thing for our clients. If you want to know what that looks like for your team, start with a Blueprint Session. Thirty minutes, no pitch deck.

mightyandtrue.com