PART 5: THE COMMAND CENTRE

Everything before this point taught you moves — a workflow here, a skill there, a chapter for each kind of work. This part teaches you a system: how to run your whole working life out of one folder that Claude Code knows inside out.

Chapter 16 introduced the Command Centre and got it installed. These five chapters are the full build: the thinking behind it, the memory that makes it compound, the design of the folder itself, the skills that make it yours, and the daily rhythm that keeps it alive. None of it requires you to be technical. All of it assumes you have a terminal open and try things as you read.

One honest note before we start: I run my actual job through this setup. Every pattern in this part comes from months of daily use, including the mistakes. Where something did not survive contact with a real working week, it is not in here.

Chapter 18: The Four-Layer Framework#

One folder that knows you#

Most people use Claude Code the way they use a search engine: open it, ask, take the answer, leave. Every session starts from zero. You re-introduce yourself, re-paste last week’s context, re-describe the process you want, re-attach the files. The tool is brilliant, but you are doing all the carrying.

The Command Centre flips that. It is a single folder that carries the context for you — who you are, what you are working on, how you like to be helped, and where everything lives. Open a session anywhere inside it and Claude starts warm. The difference in feel is hard to overstate: it is the difference between briefing a stranger every morning and working with someone who has been on your team for months.

Every durable setup I have built runs on the same four layers. They are not an invention — they are what Claude Code already is, named honestly. Once you can name them, you stop reinventing your setup for every new project and start configuring the same shape every time.

The four layers#

Layer 1: The Brain. Your CLAUDE.md — the file Claude reads automatically at the start of every session in that folder (Chapter 3 covers the file itself). It answers, briefly: who am I, what am I working on right now, how do I want to be helped, and what must never happen. It is the highest-impact file in the system, because everything else happens in the context it sets.

Layer 2: Memory. What survives after a session closes, without you re-typing it — durable preferences, corrections that stuck, lessons learned. The Brain is what you choose to load every time; memory is the longer tail that surfaces when relevant. Chapter 19 is entirely about this layer.

Layer 3: Skills. Your repeatable workflows, each runnable on one command. A process you have explained once becomes a process you can summon by name. This is the layer that compounds fastest, and Chapter 21 covers it in depth.

Layer 4: Connectors. The reach into tools you already use — your calendar, email, meeting notes, chat, the web. In Claude Code these are MCP servers and plugins (Chapter 2, Appendix B). Without them, your folder is a diary. With them, one command can read your calendar, pull the relevant meeting notes, and draft the follow-up without you switching apps.

And a quiet fifth: Git. The folder should be a Git repository — not because you are shipping software, but because Git is the cheapest safety net there is. Every change to your files is versioned, and any bold edit Claude makes can be undone with one command. Set it up on day one (“make this folder a git repository and commit everything”) and then mostly forget it is there. That is the point of a net.

When something feels off, check the layers#

The four layers double as a diagnostic. Whenever the setup feels like it is fighting you, one of them needs attention — and the symptom tells you which:

That last column is always the fix. This one table has saved me more debugging time than anything else in this part.

Your folder layout is an instruction#

Here is the design decision most people never realize they are making: Claude reads your folder structure as meaning. The names of your folders, what goes where, what each file is for — that is an instruction set, and Claude follows it the same way you do.

When I say “draft the follow-up for this morning’s call,” Claude already knows the transcript is in Meeting Transcripts/, my writing samples are in Voice Samples/, and the draft belongs in Drafts/. None of that was in my prompt. It was in the layout. A well-organized folder makes Claude dramatically more capable with zero extra prompting; a messy one makes it guess.

Four habits make a layout pay off:

1. Same shape every time. When every project folder inside your workspace looks alike, you stop making filing decisions and Claude stops guessing. Familiarity is a feature.
2. Keep everything about one piece of work together. The brief, the notes, the data, and the output for one project live in one place — not scattered across a documents folder here and a downloads folder there.
3. Separate raw from processed. Things you capture in the moment go one place; the cleaned-up version goes another. Never let the act of writing something down also force you to organize it. (Chapter 22 turns this into a daily rhythm.)
4. Name files so you can find them later. 2026-05-30-pricing-decision.md sorts itself and is findable in six months. notes-final-v3.md is lost the day you write it.

And keep one folder that is explicitly allowed to be messy. Every clean system needs a dirty drawer, so the mess has somewhere to go that is not everywhere.

When a project outgrows the folder#

Not everything belongs in your Command Centre forever. Some projects start as a folder of notes and become real things — a website, a tool — with their own repository and their own life. The signal is simple: while a project is mostly thinking (notes, drafts, decisions), it belongs in the workspace. Once it is mostly building (code, deploys, things you ship), give it its own folder and repo, and leave a one-line pointer behind. The mistake is letting a building-project sprawl inside your workspace until it drowns the thinking-work the folder was for.

Pro tips#

1. Decide the folder shape while it is empty. Reorganizing a full folder is the expensive version of the same decision.
2. Use your own instinct as the test. If you cannot guess where something lives, neither can Claude. When your guess fails, fix the layout, not the prompt.
3. Git on day one. The net you set up before you need it is the only one that is there when you do.