Building and maintaining a marketing brain on top of Claude

This is a Build Log case study. Build Log is my newsletter on building go-to-market systems as a freelance product marketing and growth consultant. Each issue collects case studies, learnings or interesting workflows I have tested throughout the week, with the working code in an open GitHub repo, linked at the end.

Case study #1 was the content pipeline I run at Rock. It takes a brief and produces a finished article straight from the terminal within 30 minutes. The system works ok on its own, but I realized that to make it run really well you're missing a second layer on top of it: the brain of the system.

What makes the blogs I write for Rock readable and on-brand is a contextual layer I have built on top of it. The brain is a personal setup I configured that carries Rock's positioning, ICP, and product knowledge.

Where I think a lot of advice gets it wrong

I have seen this a lot over the last few weeks: LinkedIn posts or X influencers claiming to have a super-set of "100 plus marketing skills for Claude" that are supposed to make marketing a breeze for you.

While it might seem like a quick fix, I think it's a counterproductive use of your time in the long run. A hundred skills from someone else is a hundred of someone else's decisions, made for someone else's product or service.

What you want is the opposite: something small and yours, one file holding your positioning and your judgment, that every AI session reads before it does anything.

It grows over time, but from your own repeatable workflows, not from a folder you copied.

You still write the strategy

The brain is not where you do strategy. It is where strategy gets encoded for the agent. Those are two different jobs, and skipping the first one is how people end up with an AI confidently producing on-brand-looking work that is strategically empty.

The strategy itself I still do by hand, as a deck of five to ten slides, or a two to three page strategy doc which includes positioning, ICP, competitive intelligence, messaging, etc.

Strategies for different client projects and my business do not live word by word in CLAUDE.md, and Claude does not edit it. High-level strategy stays static because it is the thing everything else gets measured against on a longer timeframe.

The brain is downstream of it. Once the deck or the doc exists, I hand it to Claude and it fills the relevant fields of CLAUDE.md from it: the ICP section, the positioning, the constraints. The brain is the operational, agent-facing copy of a strategy I already wrote.

When the strategy changes, it changes in the deck first, and the brain gets re-derived from it. The deck leads, the brain follows.

There's value in keeping the strategic side human. A strategy that holds steady is what lets the people you are trying to reach actually learn who you are. Hand that over to an AI and it will drift, chasing each new angle faster than any market can keep up with.

What a brain actually is

How you organize the brain does not need to be complex. For me, it is one file, CLAUDE.md, in the root of the project, plus a docs/ folder next to it.

CLAUDE.md is the part the agent reads at the start of every session, automatically. It holds what should be true of everything the agent does: what the company is, who the customer is, the positioning, the constraints, the working principles.

My main CLAUDE.md file stays short on purpose. Claude's official documentation says the same, longer files reduce how reliably the agent follows them.

docs/ holds the depth, the parts the agent only needs sometimes: the full style guide, the product detail, deeper interview insights, positioning notes, competitive intelligence, and more. CLAUDE.md points at those and the agent opens them when a task calls for it.

Everything in that list is reference material the agent reads when a task needs it. But docs/ hold more than reference, they also hold my workflows: the repeatable steps for a task, written down once so they run the same way every time, like how I publish a post or ship a launch.

Workflows vs Skills

A workflow is just another doc, and the brain points at it like everything else. So what is a skill? The same workflow, packaged.

A skill wraps the workflow in a fixed format, with a name and a description, so it can be installed somewhere else in one step. My workflow docs are the same thing as a plain file the brain already points at.

The behaviour is identical. Either way the agent reads the workflow when a task calls for it. The skill just adds a wrapper so the workflow can travel. Working alone, with a handful of workflows in one place, nothing of mine needs to travel.

So I technically do not use skills, although my workflows could be turned into skills in just a few minutes if needed. The doc does the same job with none of the packaging, and that packaging only pays off the day I hand a workflow to someone else.

Naming conventions apart, what I'm trying to get to here is that skills, workflows, whatever you name it depend on your processes tuned to your product and priorities.

Building it: Rock's brain

Rock's CLAUDE.md runs about two pages. It opens with what Rock is, a chat-and-tasks tool for agencies, and who it is for. Then the positioning, how Rock is framed against the bigger players and the constraints.

These are decisions Rock already paid to learn and should not have to relitigate. Rock tried per-seat pricing tiers once and retired them, so the brain says that pricing changes happen inside the single flat plan and not by adding tiers.

An agent that did not know that would happily propose a tiered pricing page, because tiered pricing is the obvious SaaS move. The brain is what stops it. After that, the working principles: be critical rather than agreeable, and never recommend Rock when the reader's constraints rule it out.

The content pipeline from case study #1 reads this. When it builds a brief for a new article, the editorial step pulls the positioning and the constraints out of the brain and uses them to find the angle. That is the difference between an article that is technically about the right keyword and one that argues Rock's actual point of view.

I'm not using this article to argue whether that is the best strategy, but to showcase that it helps maintain one vision instead of changing strategies every week.

Maintaining your marketing brain

A brain is not something you write once and forget about. The real work is what you do when the agent ignores things you thought were recorded in the brain, and it will.

You write a clear instruction, the agent reads the file, and then it does the other thing anyway. When that happens, you escalate. There is a ladder:

• It starts as a line in a docs/ file, read only when a task touches it.

• If it keeps getting missed, you promote it into CLAUDE.md, where it loads every session.

• If it still gets missed, you move it higher in the file and make it prominent.

• Then you change the wording. In case study #1 I wrote about labelling a step "lint" instead of "review", because the agent treats "lint" as a hard gate and "review" as optional. Forceful, unambiguous phrasing sticks where soft phrasing does not.

• As a last resort, you state the rule in more than one place.

One honest limit on all of this. The ladder nudges an agent that drifts, it does not lock anything down. A step that genuinely cannot be skipped does not belong in the brain at all, it belongs in code or a hook, something that runs regardless of what the agent decides. The lint step in case study #1 is enforced that way. The brain is for judgment, not for hard gates.

The other half of maintaining a brain is knowing what should change and what should not. Think of two layers:

• Malleable layer, the things true this month: the current plan, the experiment I am running now, a positioning angle I am still sharpening. That layer should move.

• Locked layer, the settled decisions: the pricing constraint, the ICP. That layer should not move, and writing it down is how you keep it from drifting.

People get this wrong both ways. Freeze everything and the brain goes stale. Let everything drift and the strategy erodes a sentence at a time. Maintaining the brain is mostly telling the two layers apart.

Does it travel

The brain is a plain markdown file, so it is not tied to one tool. I build mostly in Claude Code, but Cowork reads the same file. Point a Cowork project at the folder and it loads CLAUDE.md at the start of the session, the way Claude Code does. The brain travels with no extra work.

Two caveats on using the brain in Cowork vs Claude Code.

1. The escalation ladder is shorter in Cowork, it has fewer places to promote a rule to, so in practice you are editing the one file and making it more forceful. And a brain being loaded is not the same as a brain being obeyed.

2. A loaded instruction sits at the same level as something you typed into the chat. It shapes the work, it does not enforce it. Someone pushing hard against a constraint can still get the agent past it. The brain lowers how much the agent drifts.

Three brains, one shell

I run this on three projects, and the useful part is how differently the three brains are weighted based on the type of work I do.

• Rock's brain leans operational. Its biggest section is the current plan, because Rock is in a defined twelve-week push and most decisions trace back to it.

• SignalRoads, my own consultancy, has a brain that leans almost entirely on positioning, because the work is mostly judgment and there is no operational machine to steer.

• Qollab, a third client where we're building a Quantum Community, has a brain that leans on voice and community principles, because most of its output is people-facing and tone is what is most likely to go wrong.

Same shell every time: one CLAUDE.md, one docs/ folder.

What changes is which section is the biggest and gets leaned on most: the plan for Rock, the positioning for SignalRoads, the voice rules for Qollab.

Working out which section that should be, for your own kind of work, is your judgment. It is also why copying someone else's "100 skills for growth" does not get you far. The choice of which section your workflow should lean on does not carry over well, because the setup is made for their work not yours.

Start your own

The repo for this case study has a template: a CLAUDE.md shell with the sections empty, a docs/ skeleton, and a short README. You fill it from your own strategy. If that strategy is not written down yet, that is the real first step, the deck or the doc comes before the brain.

You do not need a terminal for any of this. If you work in Cowork, open a project pointed at a folder and paste one line:

Clone github.com/nicolaas-spijker/build-log, then copy the CLAUDE.md and docs folder from its strategy-brain template into the root of this project.

Cowork does the rest. You get a CLAUDE.md shell and a docs/ folder at the root, where the agent reads them. From there it is editing, not engineering: you put your positioning, your ICP, your constraints into the file, and you sharpen it every time you catch the agent guessing.

For my friends already on GitHub, you can pull the template straight from the repo: github.com/nicolaas-spijker/build-log.

A brain is not a big project. It is one file you keep a little sharper every time you catch the agent guessing. You do not need a hundred skills. You need the one file, and the judgment to keep it honest.