The Growth Repo: The First Thing Every Marketing Engineer Should Build

Chats forget. Repos remember.

Monday morning, someone on your team opens a chat and asks for ten LinkedIn posts. The model has never heard of your company. It does not know which post booked calls last month, which objection sales heard four times last week, or which words the founder refuses to use.

So it writes ten average posts. Your colleague keeps one, pastes it into a doc, and next Monday the whole thing starts from zero again.

That is the problem a growth repo solves, and it is why it comes first in the marketing engineer's job. Greg Isenberg makes the same call in his episode on the role: before any agent or campaign, build one home for everything the company has learned about selling. He suggests a GitHub repo, or a plain folder if that is easier.

The model is the same. The memory is the difference.

What a growth repo is, in plain words

A growth repo is a folder of plain text files that describe your market, your voice and your results, written so an AI agent can read them before it does any work. Nothing in it is clever. It is notes, kept in one place, in a format every tool can open.

Anthropic's engineers describe the same idea for agents in general. In their guide to context engineering, they call it structured note-taking: the agent writes notes that live outside the chat and reads them back later. Their own example is a file called NOTES.md.

The files are Markdown, the headings-and-bullets format you already type in Slack and Notion. That choice matters more than any tool. OpenAI's Codex reads an AGENTS.md file at the start of a task, Claude Code reads CLAUDE.md, and the open AGENTS.md format says more than 60,000 open-source projects already use it.

So the repo is not tied to one vendor. Switch models next year and the memory comes with you.

It is also the memory half of what we call an agent harness: the inputs, rules and checks wrapped around the model. The model writes. The harness decides what it knows and what it may do.

The folder tree

Here is the tree we would start with. It follows the folders Isenberg lists, customer truth, content, outbound, creative testing and agents, and adds three things every repo ends up needing: a front door file, an offer folder that holds your proof, and a rules folder for corrections.

Eight folders, about 25 files. You will not fill them in a week, and you should not try.

Day one is five files. The front door, the market memo, the voice file, the experiment log and one agent spec. Everything else gets created the first time a task needs it, which keeps the repo honest: every file exists because something used it.

Name files for what they hold, in lowercase with dashes. An agent told to read customer-truth/objections.md finds it. An agent told to read "the objections doc Sarah made" does not.

What goes in each file

The front door is AGENTS.md. It says in three lines what you sell and to whom, maps the folders, and lists the rules that never bend: no invented numbers, a source for every claim, a person approves anything that reaches a customer. Write it once, and make CLAUDE.md a single line, @AGENTS.md, which Anthropic's memory guide documents as the way to share one file across tools.

Keep the front door short. The same guide says to aim for under 200 lines per file, because longer files use more context and get followed less closely, and imported files do not get around that because they load at the start too.

So the front door points and the folders hold. A 40-line AGENTS.md that says where the voice guide lives beats a 900-line one that pastes it in.

The customer truth folder is the one that pays for the rest. Raw material goes in raw/, one file per call, ticket or cancel note, named by date and source; the habit of capturing it the day it happens is the subject of Collect, Don't Invent. The memo on top is rebuilt every week with a quote and a file path behind every line, and the customer truth system walks through that memo in full.

Give every raw file the same five lines at the top: date, source, who the person is (role and company size, not their name), where they were in the deal, and what happened next. Those five lines are what let an agent say "four of the six buyers who closed mentioned onboarding" instead of "people like onboarding."

Buyer-words.md is the file copywriters will thank you for. Each line is a phrase in the buyer's exact words, the file it came from, and how many times it has shown up. When the same phrase appears in a call, a ticket and a review in one month, it goes in a headline test.

The experiment log is one line per test: date, the one thing you changed, the metric, the result, the decision. One change per test, for the reason in One Variable at a Time: two changes and one result tell you nothing about either.

The agents folder holds one job spec per agent. Isenberg's advice is to write it as if you were hiring a person: the data it reads, when it runs, what it filters out, what good output looks like, what needs approval, the metric, and where it writes the result. We go line by line through that format in How to Write a Job Spec for an AI Agent.

If you use Claude Code, a spec can later become a real subagent: a markdown file in .claude/agents/ with a name, a description of when to use it, and the tools it may touch, per the subagent docs. Long procedures can become skills, which load only when a task calls for them, so they never crowd the front door.

The prompts that change once the repo exists

Here is how you know the repo works. Before it exists, a prompt has to carry the whole company, so it carries almost none of it. After, a prompt names files.

The four in the figure are the ones that change first. Each one reads before it writes, quotes its source, and finishes by writing something back.

That last step is the one people skip.

The prompt reads the repo. The repo stores the result. The result shapes next week's prompt, and nobody has to rewrite it.

You will also notice the after-prompts are longer and easier to judge. When the agent says a post came from a buyer's line, you can open the file and check. When it says nothing about where it came from, you are grading a guess.

Git or a folder

Start with whatever you will actually open. A shared drive folder works for week one, and so does a Claude Project, where you upload files to a knowledge base that every chat in the project can use.

Move to git when either of two things is true: more than one person edits the files, or an agent writes to them on a schedule. Git keeps every version of every file; the Pro Git book describes it as a series of snapshots of your project over time. That history is the point, because it shows you what the company learned and when.

On GitHub, choose private when you create the repository, and add a README that tells a new teammate how to add a file. You never need the command line for this; GitHub lets you create and edit files in the browser.

On day one, add a .gitignore file that lists .env and every raw folder holding names, emails or phone numbers. GitHub's push protection blocks known kinds of secret from public repositories by default, but it will not catch a spreadsheet of customer emails.

If you use Claude Code, a deny rule such as Read(./.env) in .claude/settings.json stops the agent from reading your keys at all; it is the first example in Anthropic's settings docs.

Keys go in .env. Memory goes in the repo. Never the other way round.

"This is a developer thing. I am a marketer."

Fair. The word repo sounds like a job you were not hired for. Open one, though, and you find text files with headings, which is what you write all day.

You do not need a single git command in month one. Claude Code's /init command will draft a first CLAUDE.md from what is already in the folder, and you can edit every file in the browser.

Here is what the skeptics get right. A repo nobody updates is worse than no repo, because it hands the agent last quarter's truth with full confidence. The fix is not more files; it is an owner and a weekly check, which is the next section.

The Weekly Diff Test

Every Friday, look at what changed in the repo this week. In git that is one screen, the list of commits. In a plain folder it is the files sorted by date modified.

Three kinds of change count. A new receipt in customer-truth, a result written into experiments/log.md, or a rule added to rules/corrections.md after someone fixed an agent's output.

If none of the three happened, your marketing ran this week and your company learned nothing from it. We call that the Weekly Diff Test, and it is the fastest way to tell a growth repo from a folder of old notes.

One empty week is a quiet week. Two in a row means nobody owns the repo.

The corrections file is where the gains add up. Isenberg's point is that every fix should become a rule in the repo.

When an agent keeps writing bland openers, show it a few strong ones next to a few weak ones and say why. Each rule is one line, dated, with the reason, so the same mistake costs you once.

The whole check takes about fifteen minutes. Read the diff, write one line in the memo about what the team learned, and pick the file that went stale. That file gets updated first next week.

Our version

We run Anar this way. The agency works in Claude Code with skill files that keep every agent on the same facts and rules, and a memory in a vector database that is searched before anything is written and updated after. The setup is in Source-of-Truth Skills.

This library is built the same way: one Python file per article, a generator, and checks that block publishing until every external citation loads, no paragraph runs past three sentences, and no 8-word run is lifted from a source. Twenty-three articles have been live since October 13, 2026, with more than 120 drafted.

A rule in a file applies to every article. A rule in someone's head applies when they remember it.

If you would rather have the repo and its first system built inside your company, that is the work in our marketing engineering engagements, one system at a time and measured before the next. The automations that write into it are covered on our AI automation page.

What to read next, and why

Claude Code for Marketers [quickstart]. The ten-minute setup that puts an agent on top of this folder. Read it the same afternoon you make the tree.

How to Become a Marketing Engineer in 30 Days [plan]. Week two of that plan is this repo. If you want the job, this is the order to do it in.

The Growth Cockpit [system]. The Monday memo that reads the experiment log and tells the team what to test next. It is only as good as the repo under it.

How We Run a Marketing Agency as Marketing Engineers [proof]. Our own stack, checks and pipelines, with the numbers. The best argument that a folder of text files can run real work.

So the simple takeaway is this: if your AI does not read your files before it writes, it starts from zero every Monday, and so do you.