Client engagements

For consulting or any role with multiple concurrent client engagements, the basic command-centre structure needs an addition. Putting all clients into a single shared projects.md produces two problems:

Context bleed. When working on Client A, you don’t want Client B’s strategy or pricing accidentally appearing in a draft. The shared file makes this a permanent risk.

Context overload. Even if bleed weren’t a concern, loading 3–5 active engagements’ worth of detail into every triage run is wasteful — Claude pays attention to projects irrelevant to today’s task.

The fix is a clients/ directory alongside context/, with one subfolder per active engagement, plus a session activation pattern that controls which client is loaded at any moment.

Folder shape

~/command-centre/
├── CLAUDE.md
├── README.md
│
├── context/                        ← shared identity layer, always loaded
│   ├── role.md
│   ├── priorities.md
│   ├── people.md                   ← internal + industry contacts only
│   ├── projects.md                 ← internal/non-client projects only
│   ├── voice.md
│   └── anti-voice.md
│
├── clients/                        ← client engagements, loaded on demand
│   ├── client-a/
│   │   ├── CLAUDE.md               ← client-specific overrides and index
│   │   ├── context.md              ← engagement state, decisions, contacts
│   │   ├── inputs/                 ← their files (PDFs, decks, transcripts)
│   │   └── outputs/                ← deliverables and drafts for this client
│   ├── client-b/
│   │   └── ... (same structure)
│   └── archive/                    ← engagements that have ended
│       └── client-x-2024-12/
│
├── workflows/
├── scripts/
├── templates/
└── outputs/                        ← non-client outputs (briefs, internal decks)

The shared context/ layer represents who you are and how you work — your voice, role, priorities, internal team, industry contacts. It loads on every session regardless of which client you’re working on.

The per-client clients/<name>/ folder represents who this client is and what their engagement looks like. It loads only when you activate a session for that client.

Per-client files

clients/<name>/CLAUDE.md — a short index file, similar to the root CLAUDE.md but client-scoped. Lists what files exist in this engagement folder, any client-specific rules (their terminology, tone preferences, decisions made), and pointers to their key people.

clients/<name>/context.md — the engagement metadata:

• Engagement scope and timeline
• Key decisions made and why
• Their stakeholders with roles, comms style, what they care about
• Their terminology and house style (“they call it ‘consumer payments’ not ‘B2C’”)
• Current state, what phase, what’s next, what’s blocked
• Anything that would be costly to re-explain

clients/<name>/inputs/ — raw source material received from the client. PDFs, spreadsheets, transcripts, their brand assets if you’re producing deliverables in their template.

The difference between context.md and inputs/ matters: context.md is written by you and loaded into every task for this client. inputs/ is received from them and loaded only when a specific task needs a specific file — Claude doesn’t read every PDF in inputs/ each session.

Session activation

The bleed-prevention model relies on Claude knowing which client is in scope for the current session. There’s no built-in concept of “I’m working on Client A right now” — without an explicit activation, Claude is in neutral state and might load any client folder that seems relevant to the task.

Activation is a statement at the start of a client session that does two things: loads the right client’s context, and signals that other clients are off-limits.

The recommended phrasing:

Activate [client] session — load clients/[client]/CLAUDE.md and
context.md, treat other clients as out of scope.

Use this verbatim as the first message in any client session, before any task instructions. It’s deliberately formal because the formality creates a visible marker in your session history and trains the habit.

For non-client work (morning brief, internal email, internal deck), no activation is needed. The shared context layer loads automatically; client folders stay unloaded.

Three habits that make manual activation reliable

Activation is a manual step, which means the failure mode is forgetting. Three habits reduce the risk:

Activate first, work second. Even when it feels redundant. The discipline of always-first turns it from a thing-you-remember into a thing-you-do automatically.

Use the formal phrasing every time. “Working on Acme” is too casual to stick as a habit. The full activation phrase forces deliberateness.

Re-activate when sessions stretch. If you’ve been silent for 20 minutes and pick up again, restate the activation. Sessions are growing context windows, not atomic units — a quick re-activation costs nothing.

The bleed-prevention rule

Activation tells Claude which client is in scope. The bleed-prevention rule tells Claude what to do about other clients. It lives in your root CLAUDE.md:

## Client engagement isolation

When a client session is active (you've been asked to load a
specific client's files from clients/<name>/), treat all other
client folders as out of scope for the duration of the session.

Specifically:
- Do not read files from any clients/<other>/ folder
- Do not reference content, decisions, or contacts from other
  client engagements, even if they seem relevant or comparable
- Do not include comparisons between clients ("similar to what
  we did at Meridian") unless I explicitly authorise it for
  this session

If a question or task would require crossing client boundaries
(genuine cross-client comparison, pattern recognition across
engagements, applying a framework from one client to another),
pause and ask me before proceeding. I will explicitly say
"load X and Y for this comparison" if I want it.

If no client session is active (you're working on internal
tasks, brief, internal email), the rule doesn't apply — client
folders simply aren't loaded.

What the rule does and doesn’t do

Does: establishes a default refusal behaviour when content from a non-activated client folder would be referenced. Forces Claude to ask you before crossing the boundary.

Doesn’t: prevent bleed at the file-system level. Claude can still read other clients’ files if instructed. The rule is a behavioural guardrail, not a permission boundary. If your firm’s policy requires actual file-system isolation between clients, this rule isn’t sufficient — you’d need separate user accounts or separate machines, which is a different conversation.

For accidental bleed, which covers most real consulting workflow risks, the rule is effective. For deliberate or instructed bleed, it isn’t — but you also have visibility into your own instructions, so the risk model is different.

Keeping shared people.md safe

The shared identity layer doesn’t get bleed-controlled. context/people.md loads on every session, including client sessions. This means if you put project-specific notes about a contact in shared people.md, that information is visible regardless of which client is activated.

Three rules of thumb keep this acceptable:

Keep entries factual, not narrative. “Jane Smith, Senior Analyst at Forrester. Covers payments and fintech.” is fine. “Jane Smith, has been asking us about our work with Client B” is the bleed risk in concrete form. Notes should focus on role and communication style, not project mentions.

Move project-specific stakeholder context to the client’s folder. If you want to track that Jane is interested in Client B’s pricing work, that note belongs in clients/client-b/context.md under their stakeholder map, not in shared people.md.

Audit quarterly. When you do the quarterly maintenance pass on voice.md and anti-voice.md, scan people.md for client names or project codenames. Anything you find probably wants moving to the relevant client folder.

The same logic applies to context/projects.md — that file is for internal/non-client work only. Client engagements live in their own folders.

When a client engagement ends

Client folders don’t stay live forever. When an engagement closes:

mv clients/acme clients/archive/acme-2025-03

The archive prefix prevents Claude from treating ended engagements as current. It also preserves a record without forcing you to delete material that might matter for future reference.

Don’t archive too eagerly. Some engagements have a quiet phase between active work and formal close — keep them in clients/ during that phase. The signal to archive is “this engagement is genuinely over and I’m unlikely to need session activation for it again.”

Periodically — quarterly is fine — review clients/archive/ and decide whether to keep folders or delete them, per your firm’s data retention policy. The archive isn’t a permanent store; it’s a holding area between active work and final disposition.

Three things to check before populating this structure

Firm policy on client data on local disk. Some consulting firms require client materials to stay in document management systems and never touch local devices. Before populating inputs/ heavily, confirm what’s allowed. This isn’t a Claude problem — it’s an “are you allowed to put client decks in this folder at all” question.

Confidentiality scope. The bleed-prevention rule handles file-level isolation between client folders. It doesn’t handle conversational drift in long sessions, or content surfaced via Claude’s conversation search across past sessions. End client sessions when the task ends; don’t run all-day Claude sessions across multiple clients.

Multi-machine consistency. If you work across a personal laptop and a work laptop, the clients/ folder structure needs to exist on whichever machine handles client work — and the bleed-prevention rule needs to be in the CLAUDE.md on both. Asymmetric setups are where bleed creeps in.

Setup implications

This structure adds steps to the setup sequence (covered in section 35):

• Phase 1 — Foundation: include clients/ and clients/archive/ in the mkdir -p command
• Phase 1 — CLAUDE.md: include the bleed-prevention rule
• Phase 2 — Context: shared people.md and projects.md content scoped to internal/cross-client only
• New phase between 2 and 3: per-client folder setup for each active engagement
• All workflow files reference client activation as a precondition where relevant