The Command Kit

The Command layer is the shared brain you maintain with your AI. It's the framework, the ethos, the folder structure, the most simplistic boiled-down framework of your business. Highest-level view: what your business does, who it serves, why it's important, why it's special. It's where you, the captain, work. It's what your AI references. It's what your agents add to and reorganize as the work gets done.

If you only take one thing away: Command is your shared brain with your AI coworkers. Everything else follows.

What's actually in mine

My Command Kit at the time of writing had a fixed top-level structure. Each top-level folder has a job. Nothing is decorative.

• CLAUDE.md, the schema. Tells the AI where things go, who works here, what we're trying to do, how I want things done. This is the one file I'd save if I lost everything else.
• raw/, immutable source material. PDFs I download, web clips, research jobs, agreements, meeting transcripts. The intake folder. Things go in, never come out.
• wiki/, LLM-compiled knowledge. One entity page per venture, client, person, or concept. Cross-referenced with wikilinks. Maintained by Claude as I work.
• ventures/, code and ops folders for each business or project. Git repos, project files, deployable software.
• missions/, thin files linking to Linear issues. Just navigation aids, Linear is the source of truth.
• templates/, recurring patterns. Meeting log format, decision template, venture page skeleton. The structure I want preserved across new entries.
• atlas/, navigation Maps of Content (MOCs), Obsidian-style. The way you find things when you don't remember exactly where they live.
• calendar/, daily notes, journal. Human-authored.
• tools/, reusable scripts. Fixed inventory. New scripts get scrutiny before they earn a slot.
• archive/, deprecated, completed, one-off. Where things go to die without losing the history.

The structure mirrors how I actually think about my work. Anthropic's own best practices recommend the same: organize folders to mirror how you think. Project → areas (marketing, finance, ops) → specific things. Each level can hold its own CLAUDE.md.

The first 24 hours, for someone with nothing

If you've never built a Command Kit, here's the order of operations for day one:

1. Clone the open-source starter. git clone https://github.com/shipwithmax/command ~/command. Or grab it from the product page.
2. Open it in Claude Code. cd ~/command && claude. Optionally also open it in Obsidian, the markdown files render beautifully and the wikilinks work.
3. Edit CLAUDE.md. Replace the placeholder with: who you are (one paragraph), what you're working on (one paragraph), how you want Claude to work with you (3-5 bullet points). Save.
4. Drop one real document into raw/. A PDF of a key document. Your business plan. A meeting transcript. Anything you'd want Claude to know about.
5. Ask Claude to read it and create a wiki entry. "Read raw/[filename]. Create a wiki page summarizing the key points and link to the source." Watch what happens.
6. Update CLAUDE.md with one thing you learned. Maybe the wiki page Claude made was structured wrong. Maybe the way it summarized was off-tone. Capture the correction in CLAUDE.md so it doesn't repeat.

That's day one. You've now run one rotation of the Captain's Flywheel inside your Command Kit. Multiply that by 90 days and you have a brain Claude understands.

Three things I learned the hard way

1. Connect your project management tool early. For me, it's Linear. Every task I do gets linked back. Every change I commit references its issue. This forces the system to stay contextually aware: what is this project, what task am I doing, how does it ladder up. Without this, OpenClaw-style autonomous agents go off the rails because they have no anchor for what matters this week vs. next quarter.
2. Don't build dashboards too early. The only thing worse than no dashboard is a busy dashboard you don't actually use. I've built dozens for my clients, operations, sales, marketing, content, analytics, and I'm telling you: until you intimately understand what data analytics you need in your life, every dashboard is premature optimization. The Command Kit is the dashboard. Markdown is the dashboard.
3. Git everything. The folder must be version-controlled. Without git, you can't roll back when an agent reorganizes badly. You can't see what changed last week. You can't audit Claude's edits. You can't safely let agents touch the structure. Git turns the Command Kit from a fragile pile of files into a system you can let your crew work in.

The boundary question, Command vs. Compute

Where do you draw the line? Easy heuristic:

• Command holds theory, the ideas, decisions, frameworks, knowledge that make your business yours. Stuff you'd want to keep if you switched AIs. Stuff that requires you to author and update.
• Compute holds execution, the workers, scripts, agents, MCPs, deployed services that turn theory into output. Stuff you can replace or refactor without losing anything irreplaceable.

Edge cases: Where do prompt templates go? Command (they're authored by you, they encode your taste). Where do API keys go? Outside both, secrets file, never in the repo. Where do agent configs go? Compute (they're disposable execution detail). Where do "lessons learned" go? Command, in the relevant entity page or concept page.

Anthropic's three-layer memory model

As of March 2026, Anthropic ships a three-layer memory system. We integrate with it:

1. CLAUDE.md (you write). Explicit instructions, "AI onboarding plus operating manual." Brief, explicit, high-signal. Not a knowledge dump.
2. MEMORY.md (Claude maintains). Auto-memory file Claude writes itself based on what it learns about your patterns and preferences. Loads first 200 lines at session start. Routing rules don't go here, they belong in CLAUDE.md.
3. Chat memory (cross-session). Claude remembers context from prior conversations and surfaces it when relevant.

The Command Kit works on top of all three. CLAUDE.md sits at the root of your folder. MEMORY.md gets generated next to it. The wiki, raw, ventures, and tools folders give Claude the explicit context it needs alongside the implicit memory it builds. Together: a brain that gets smarter with every session.

How Command evolves

You'll know your folder structure is wrong when finding things gets harder, not easier. When you're afraid to add a new entry because you don't know where it goes. When Claude keeps misfiling new content. That's the signal to reorganize.

The most common evolution path I've seen: start with the open-source starter; add one new top-level folder when you feel friction; merge or split sub-folders when patterns emerge; promote frequently-referenced entries to atlas/. Don't restructure for fun. Restructure when the friction tells you to.

When Command fails

The most common failure: bad context produces bad output. Claude can't read between the lines if the lines aren't there. The fix is almost always upstream, improve the CLAUDE.md, write a clearer wiki entry, drop a missing source into raw/. Once. Fixed forever.

The second-most-common failure: you stopped using Command and started bypassing it. Easier to just type the prompt directly. Faster in the moment. Slower in aggregate. Discipline of returning to the folder, of writing context once and reusing it, is what makes the system compound. Skip it and you're just doing prompt engineering, which (per our doctrine on context) is a much weaker leverage point than context engineering.

This is what Peter Naur called "theory building" back in 1985: the program lives in your mind. Code is its shadow. The Command Kit is the explicit articulation of the theory, so the AI can render the shadow without losing the thread.

What changed since I wrote this (updated August 2026)

I published this in May 2026 and then used it every working day for the next fifteen months. Some of it held. A lot of the specifics did not. Here is the honest diff, because a doctrine article that never gets corrected is just a press release with footnotes.

What held up

Three claims survived without amendment. CLAUDE.md is still the one file I would save. Git everything turned out to be more important than I argued at the time, not less. And don't build dashboards early aged extremely well: the markdown is still the dashboard, and every dashboard I have built since has been useful only after the underlying folder was already right.

The Command versus Compute boundary held too. I have not once been confused about which side something belongs on since writing it down.

What I got wrong

1. Ten folders was three too many

The failure was not that the folders were wrong. It was that filing required a decision. Every new thing triggered a small negotiation: is this a wiki entry or a venture note, an atlas page or a template? A structure that makes you deliberate is a structure you eventually stop using, which is exactly the bypass failure I warned about at the end of this article. I wrote the warning and then walked straight into it.

The rule that replaced it: when something new shows up, ask what kind of thing it is, and the answer should name the folder without hesitation. Anything that failed that test got merged or deleted.

2. Clients were a folder. They should have been a field.

The original structure had ventures in one place and client work drifting toward its own. The moment a client became a venture (or a venture picked up a client) the boundary produced arguments about where a file lived.

Everything now lives in ventures/ and carries a type: field in its README header: venture or client. The client list is a filter, not a directory. The general rule, which has paid off several times since: if a category is something you would want to filter by, it belongs in metadata, not in the path. Folders are for things that are genuinely different. Fields are for things that are the same shape with a different label.

3. Two canonical copies is one too many

For a long stretch the vault lived in a synced cloud drive, because that is comfortable: it shares, it syncs, non-technical teammates can open it. The cost only shows up once agents are writing into it. No diff. No blame. No rollback. No way to review what changed while you slept.

The markdown moved into git in July 2026. Of roughly 1,096 markdown files inventoried, 782 survived the move as genuinely relevant; the rest were dependency trees, build output, and duplicates that had quietly accumulated. Large binaries, video, and anything a teammate edits in a browser stayed in the drive and are linked rather than stored.

4. The index turned out to be the product

This is the correction I did not see coming, and the one worth the most.

I built the vault assuming the content was the asset. It is not. Once there is enough content, the binding constraint is navigation: an agent asked a simple question will happily search hundreds of files to answer it, and you pay for that in latency, in money, and in a context window filled with things that were not the answer.

So the instruction file now carries an explicit navigation protocol, and it reads like a traffic rule rather than a philosophy:

1. read the index first. it is loaded automatically every session
2. open ONLY the one file the index points to. then stop
3. never search for these (deterministic locations)
     current state → that entity's README.md
     history + decisions → that folder's log.md
     what we are working on → the projects index
4. archive/ is COLD. never read unless explicitly asked
5. if the index genuinely misses something, find it, then
     ADD A LINE TO THE INDEX so nobody pays that cost twice

Step five is the compounding one. Every miss makes the index better, so the vault gets cheaper to use as it grows instead of more expensive. That is the opposite of how most knowledge bases age.

One correction to what I wrote above about Anthropic's memory layers: in practice I do not let the index write itself freely. MEMORY.md is the index of where things live, capped at about 200 lines, and it is deliberately not a dump. The cap is the whole discipline. An index that grows without limit stops being an index and becomes another thing to search.

5. Append-only, one file per person per day

The original had one person in it. Me. The moment a second person and several agents were writing into the same vault, the failure mode changed from "where does this go" to "who just overwrote my paragraph."

The fix was structural rather than social. Write new files, one per person per day. Append to logs, newest at the top. Never edit someone else's words. Two people can commit in the same second safely, because they are never in the same region of the same file. Where something is genuinely superseded it gets moved to the archive rather than deleted, so the history survives the correction.

The side effect became more valuable than the fix. Because every notable event is a timestamped line in a dated file, "what did we ship on Thursday morning" is now one search across the logs. That timeline has settled more arguments than any dashboard I have built.

6. Write down what agents may do without asking

Once agents can write to the vault, the ambiguous middle is not "can it do this" but "does it need me first." Leaving that unwritten means either an agent that asks permission for everything, which you will start ignoring, or one that does not ask when it should.

It is now three tiers, written into the instruction file: routine capture goes straight in; structural changes need a reviewed change request even when an agent is confident; and anything destructive, irreversible, or touching a security boundary stops and asks a human. The value is not the specific tiers. It is that the tiers are written down in the same file the agent reads before it starts.

7. Let a script look for secrets before you commit

The last one is unglamorous and I would now do it on day one. A repository holding the theory of your business will eventually have something in it that should not be there: a key pasted into a note, a number that belongs in a private file, a document that crossed a client boundary.

There is a small validator that runs over the vault checking for credential-shaped strings, payment coordinates, storage-boundary violations, and missing required files. It is maybe an hour of work and it changes how freely you can let agents write, because the check no longer depends on anyone remembering to look.

What I would tell someone starting today

1. Start with fewer folders than feels right. Add one only when filing something makes you hesitate. You cannot predict the right structure and you do not have to.
2. Put it in git on day one, even alone, even if you barely know git. The day an agent reorganizes badly you will either have a diff or you will have a story.
3. Write the index before you have enough content to need it, and cap it. It is the file that decides whether the vault gets cheaper or more expensive as it grows.
4. Make one rule about what agents may do unattended, and put it where they read it.
5. Expect to be wrong about the structure and leave the corrections visible. The reasoning ages better than the layout.

I have an existing folder I use as context for my AI. I want you to audit its structure against one test, and be blunt.

The test: when a new piece of information arrives, can I name its folder without hesitating? Any folder that requires a judgment call is a folder I will eventually stop using.

Read the folder tree. Then tell me:
1. Which folders overlap enough that filing is ambiguous, and which one should absorb the other.
2. Which folders things go into but never come out of. Those are graveyards, name them.
3. Which distinctions I am storing in the path that should be a field in the file's header instead.
4. What an index file should contain so you could answer most questions without searching the whole folder, and where my current structure would force you to search.

Do not suggest new folders unless you can name the specific thing that has nowhere to go today.


End by asking me one question: "Which parts of this feel most uncertain — want me to explain them, or should I just build it for you?"