9 Building Blocks for Running Claude Code as a Persistent OS Across 18 Businesses

A developer on r/ClaudeAI describes running 18 Claude Code instances not as isolated projects, but as instances of a shared operating system. Each instance runs a different business (strategy, product, marketing website, threat intelligence, three consulting clients, personal brand), all sharing a common skeleton that is updated once and propagated selectively.

The 9 Building Blocks

1. Build a skeleton with selective propagation

• Instead of building one project per workspace, the developer built a template containing plugins, rules, agents, hooks, schemas, and commands.
• When starting a new business, the template is cloned. Each instance inherits the entire OS but diverges on canonical files, memory, output, and project state.
• The update CLI syncs plugins, rules, agents, hooks, and schemas; it never touches memory, output, canonical, or my-project (those accumulate per instance).

2. Move state out of prompts and into code

• LLMs are bad at remembering; code is designed for it. State like voice rules, style preferences, banned words, and recent decisions was moved into MCP servers.
• Voice linter, lead scorer, schedule validator, loop tracker run in Python and return structured data.
• Rule of thumb: if you explained something to Claude more than twice, it should be code.

3. Use receipts, not status fields

• Status fields (issue closed, PRD shipped, test passing) are unreliable because the LLM can claim anything.
• Workflows were rebuilt around receipts — a script writes a verification record before an issue can be marked verified. The model cannot lie about whether code ran.

4. Build a wiring-check gate

• Half-built features rot silently in AI repos because nothing breaks.
• A /wiring-check command was built. Before a task is done, it verifies every new skill has a trigger, every new hook lives in settings.json, every new MCP tool sits in the server, every new bus file has a producer and a consumer.
• "I think it works" fails the gate. "I ran X, got Y" passes.

5. Make rules auto-load, not slash commands

• Rules in .claude/rules/ load automatically. The voice rule fires on outbound text, the AUDHD rule on anything actionable, the social-reaction rule when sharing someone else's post.
• No remembering or willpower required.

6. Lint style in code, not in prose

• A voice document was ignored by Claude half the time. The banned word list was moved into a Python scanner that blocks emdashes, AI hype words, and 40+ other tells.
• "The model can't talk its way past a regex."

7. Track file dependencies with a graph

• Canonical files reference each other. A ripple-graph.json maps dependencies. Editing talk-tracks flags current-state and the engagement playbook for review.

8. Chain sessions with handoffs and memory

• "Sessions are drafts. The work is everything that survives the session."
• Each session ends with /q-wrap, which writes a handoff doc, a memory update, and a status receipt. /q-morning reads all three.

9. Treat the environment as a substrate, not an editor

• Most developers treat Claude Code as a smarter editor. The shift comes when you stop thinking of sessions as the unit of work and start thinking of the whole environment as a substrate to build on top of.

This approach is aimed at developers who want to scale Claude Code across multiple projects without duplication or state leaks. The full thread includes discussion of implementation details and the trade-offs.