CCSwitchboard

Here is the part most people would not think about, and it is the part that actually makes the thing work.

Claude.ai does not know how to run this on its own

Nothing inside Claude.ai knows what a ccsw block is, or that jobs get a two-word name, or that you wait for one result to land before firing the next. The system is only half code. The other half is instruction, and that instruction lives outside the model, in durable notes and files that Claude.ai reads at the start of a thread.

Two places the operating knowledge lives

1. claude.md files. Plain text files that sit in a project, plus one global one. Every Claude Code run reads them the moment it starts, so they are the right home for the mechanical facts a run needs before it touches anything: the drive map, the deploy command and its gotchas, the coding conventions to hold to. A real one for this project looks like this:

# CCSwitchboard
Drive map (VM shared folders: host path -> VM drive)
C:\wamp\www   -> V:
~/Desktop/AS  -> Z:
Deploy
Always deploy with a TARGETED put, naming only the files that changed:
php deploy.php --push <changed files>
NEVER run a bare php deploy.php --push - the full-tree mirror is
flaky on this host and deletes server files not present in dist.
Conventions

ASCII punctuation only in code edits (no smart quotes, no em-dash).
After a working change, commit AND push together.

2. Claude.ai's memory. This is the planning side, the chat thread where I think out what to do next. What it needs is not build facts but the rules for driving the machine: how to write a dispatch block, the workflow to hold to, and where each project last got to. Concrete things I keep here:

• The dispatch format itself: fire a job by writing a ccsw block with a name, the thread, the model, the working directory and the prompt.
• The workflow rules: one job in flight per repo, wait for each result before firing the next, always give a job a two-word name and refer to it by that name, and re-fire when a repo frees up.
• Handoff state: what a given project's thread was in the middle of, so a new thread can carry it on.

I hold those notes in BrainMop, my own notes app, and use it as Claude.ai's long-term memory. I built it, and it has an interface Claude.ai can read from and write to directly. The notes are tagged and kept out of my normal view, so they act as memory without cluttering the app.

How a fresh thread knows which notes to pull

The notes only help if a new thread reads the right ones. That is what Claude.ai's own memory is for. A short standing memory tells Claude.ai, at the very start of a thread, to reach into BrainMop over MCP and pull the notes for whatever the thread is about, before it does anything else. A couple I keep set up:

MEMORY
I drive Claude Code through CCSwitchboard. At the start
of any CCSwitchboard thread, pull my BrainMop notes
tagged "ccsw" through the BrainMop MCP tool - that is
where the dispatch format, the workflow rules and each
repo's handoff state live. Read them before doing
anything else.

MEMORY
To fire a job, write a ccsw block: name, thread, model,
working directory, prompt. One job per repo at a time.
Wait for a result before firing the next.

A handoff does the same thing for a single project. When one thread hands a project to a fresh one, the handoff names the project, and that name is the key the new thread uses to pull the matching notes over MCP:

Handoff: picking up the DabbleLabs website work.
Pull the "dabblelabs" BrainMop notes for where we got
to, then show me the queue.

A starter kit you can lift

If you want to run the same pattern, here is a sanitised version of the three pieces above, written out generically so you can copy and adapt them. None of it holds real hosts, paths or credentials. Swap the placeholders (relay.example.com and the like) for your own.

1. The claude.md snippet - the mechanical facts each Claude Code run reads at startup: the drive map, the deploy rule, the conventions.

# ExampleProject
Drive map (VM shared folders: host path -> VM drive)
C:\work\www   -> V:
~/projects    -> Z:
Deploy
Always deploy with a TARGETED push, naming only the files that changed:
php deploy.php --push <changed files>
NEVER run a bare php deploy.php --push - the full-tree mirror is
flaky on this host and can delete server files not present in the build.
After deploy, clear the cache:
ssh prod 'uapi NginxCaching clear_cache'
Conventions

ASCII punctuation only in code edits (no smart quotes, no em-dash).
After a working change, commit AND push together.
One job in flight per repo. Finish and land it before starting the next.

2. The Claude.ai memory block - the small, always-true pointer that tells a fresh thread which notes to pull, and the one-job-per-repo rule.

MEMORY
I drive Claude Code through CCSwitchboard. At the start of any ccsw
thread, pull my notes tagged "ccsw" from my notes store over MCP -
that is where the dispatch format, the workflow rules and each repo's
handoff state live. Read them before doing anything else.
To fire a job, write a ccsw block: name, thread, model, working
directory, prompt. One job per repo at a time. Wait for a result
before firing the next.

3. The MCP memory note - the large, changing detail the pointer points at: the full shape of a dispatch block and the workflow rules.

CCSW DISPATCH CONVENTIONS
Fire a job by writing a ccsw block. The relay picks it up and runs it
headless on the VM, then types the result back into this same thread.
ccsw
name: two-words
thread: this-thread-id
model: opus | sonnet | haiku
dir: example-project
prompt: One clear instruction for the run. Keep it self-contained -
the run reads the project's claude.md, not this chat.
WORKFLOW RULES

One job in flight per repo. Never fire a second into a running repo.
Give every job a two-word name and refer to it by that name.
Wait for a job's result to land before firing the next.
When a repo frees up, re-fire the next queued job for it.

Grab the full starter kit as a file →

Why bother pushing it out of the model's head

Because chat threads are throwaway, and their context gets worse the longer a session runs. If the knowledge of how to run the system lived only in the thread's own working memory, it would rot as the thread got long, and handing the project to a new thread would mean teaching it everything from scratch. Offloading that knowledge to a durable store is what lets a freshly woken thread act correctly without relearning the system first. It is also why a handoff carries no state across: the new thread reads the same notes and picks up where the old one left off.

This is what makes the whole system work. The point of it is to wake a turn-based chat when there is work to react to. Claude.ai's memory is how the woken chat knows what to do once it is awake.