Updated July 2026: I’ve folded in a few Claude Code changes that landed after this piece originally went live, skills maturing into the primary way to package a reusable workflow (they invoke on the same /name syntax as slash commands but carry frontmatter, references, and auto-loading; custom commands have since been merged into skills, and existing command files keep working), native auto-memory at ~/.claude/projects/<project>/memory/MEMORY.md, and the .claude/agents/ folder for sub-agent personas. The plugin ecosystem has also matured, which is how I now distribute the skills, agents, and hooks I used to keep loose in ~/.claude/. The structure of how I work hasn’t changed; the underlying tools have.
TLDR; One CLAUDE.md per client, a cross-client DASHBOARD.md, narrow custom skills for each role, and sub-agents for independent parallel work. Campaign state lives in TRACKER files so nothing depends on memory. The system costs about five minutes a session, and it’s what makes six concurrent client engagements manageable without dropping quality.
I’ve been using Claude Code as my primary work tool for the past year. Not for side projects, for real client work across six concurrent projects:
- an education provider
- a recruitment agency
- an AI staffing firm
- a B2B SaaS product
- a speaking business
- a theme park content site Different industries, different stacks, different kinds of work.
This isn’t a tutorial on installing Claude Code or running your first /init. There are plenty of those. This is how I use it day to day. The setup that makes managing multiple clients possible without losing your mind, plus an honest account of where it works brilliantly and where it still falls short.
The system, in brief:
- One
CLAUDE.mdper client directory: brief, rulebook, context file rolled into one DASHBOARD.mdfor daily cross-client status at a glance- Custom skills (slash commands) for each role: strategist, writer, SEO, CRO
- Sub-agents for parallel, independent tasks
- Memory vault for cross-project knowledge that needs to persist between sessions
My directory structure and why it matters
Every client has their own directory. Inside each one, a CLAUDE.md. That’s the foundation.
When Claude Code starts a session in a directory, it reads the CLAUDE.md automatically. It’s the brief and the rulebook. I put everything in there that Claude would otherwise have to guess or ask about:
- what the client does
- who their audience is
- brand voice rules
- the tools they use
- what I’m currently working on
- what conventions to follow
A simplified version:
# Client: [Education Provider], CLAUDE.md
## About this client
Online education provider. Nationally recognised vocational training.
Courses in counselling, mental health, chaplaincy, child/family intervention.
## Brand voice rules
- Use "learner" not "student", "trainer" not "teacher"
- Australian English spelling (organisation, colour, recognise)
- No competitor names in any content
- Sentence case headings only
- Oxford comma
## Current campaigns
- SEO content strategy: /education-provider/new-courses-seo/
- Backlink building: /education-provider/backlink-building/
- Google Ads landing pages: /education-provider/google-ads-landing-pages/
## Key files
- Brand guidelines: BRAND_GUIDELINES.md
- Tone of voice: TONE_OF_VOICE.md
- Active tracker: new-courses-seo/TRACKER.md
- Dashboard: ../../DASHBOARD.md
Clean, specific, maintained. Every time I open a session for that client, Claude knows the context without me reciting it.
The directory structure follows the same pattern across all clients:
marketing/
├── DASHBOARD.md ← cross-client overview
├── .claude/
│ ├── settings.json ← permissions, hooks, model defaults
│ ├── skills/ ← skill definitions live here
│ │ ├── marketing-strategist/
│ │ ├── content-writer/
│ │ ├── seo-optimizer/
│ │ └── brand/
│ └── agents/ ← sub-agent personas
├── client-a/
│ ├── CLAUDE.md
│ ├── TONE_OF_VOICE.md
│ ├── VISUAL_BRAND_GUIDELINES.md
│ ├── data/
│ └── campaign-name/
│ ├── TRACKER.md
│ ├── briefs/
│ ├── research/
│ └── content/
└── client-b/
└── ...
(Claude Code’s own auto-written memory lives outside this tree, at ~/.claude/projects/<project>/memory/, machine-local and never committed; see the update note above and the memory section below.)
The consistency matters. Managing six clients and switching between them throughout the day, knowing exactly where everything lives removes friction. Claude always knows where to save output, where to read from, and how one file relates to another.
The daily workflow: DASHBOARD first
I start every working day the same way. Open the project root, read DASHBOARD.md.
The dashboard is a markdown file with one table per client. Each row is a campaign, with columns for current phase, what’s been done, what’s pending, when it was last updated. Sixty seconds to scan, and after that I know exactly where every client stands.
It looks like this:
## Client A (Education Provider)
| Campaign | Phase | Progress | Next Action | Updated |
|----------|-------|----------|-------------|---------|
| New Courses SEO | Execution | 24/24 content written; 13/15 published | Fix category page cannibalization on Youth Work | 2026-03-22 |
| Google Ads CRO | Execution | Audit complete, 22 issues, 6-test roadmap | Implement P0 fixes (price transparency, phone links) | 2026-03-20 |
Then I open the relevant TRACKER.md for whichever campaign I’m working on. The tracker has the full task list with statuses: pending, active, done, blocked. Combined with the dashboard, I can pick up exactly where I left off, even if I haven’t touched that client in four days.
Context switching is the enemy of deep work. If every time I switch clients I have to reconstruct “where am I up to with this?”, I lose 10-15 minutes per switch. The dashboard and tracker eliminate that. Claude reads them too, so when I start a session, it already knows the current state.
Custom skills
This is where the setup gets useful. I’ve built a library of custom skills, definitions in .claude/skills/ that Claude Code loads based on context.
(A note on terminology: skills and slash commands used to be separate concepts. Anthropic has since merged custom commands into skills: .claude/commands/deploy.md and .claude/skills/deploy/SKILL.md both create /deploy, existing command files keep working, and the docs recommend a skill for new work.)
The primary orchestrator is /marketing-strategist. When I invoke it, Claude takes on the role of a senior marketing strategist: it plans campaigns, decomposes work into tasks, assigns those tasks to specialised sub-skills, coordinates dependencies, reviews output. It doesn’t write content or build ads. It directs the work, like a project lead who knows which specialist to bring in for each piece.
From there, /content-writer handles blog posts, landing page copy, ad copy, and meta descriptions. /seo-optimizer runs keyword research, writes content briefs, does on-page audits. /brand creates tone of voice documents and brand guidelines. /cro handles conversion rate audits and A/B test design.
Each skill has its own SKILL.md defining its responsibilities, workflow, output format, and standards. A fragment from the content-writer skill:
---
name: content-writer
description: Marketing copywriter producing blog posts, ad copy, landing page
copy, emails, social media posts, and meta descriptions from briefs.
---
## Activation
This skill is invoked with `/content-writer` or delegated by other skills.
## Workflow
1. Receive brief
2. SEO check, if brief lacks keyword specs, ask about DataForSEO research
3. Vault check, search memory for existing client/industry knowledge
4. Research, review provided data, layer with vault findings
5. Outline, create structured outline, share for approval on long-form
6. Draft, write following brief specs
7. Optimize, apply SEO guidelines, check readability, verify keyword usage
Invoking a skill in practice: I open a session in the client directory and type:
/marketing-strategist
I need to plan a 3-month SEO content campaign for [client].
Context: keyword research is in research/keyword-competitor-research.md.
Brand voice: TONE_OF_VOICE.md.
Goal: drive organic enquiries for their two new course offerings.
The marketing strategist reads the research, reads the brand guidelines, plans the campaign, writes a brief for each downstream skill. I can then invoke /content-writer with those briefs, or let the strategist delegate.
The key is separation of concerns. The strategist doesn’t write copy. The content writer doesn’t make strategic calls. Each skill has a narrow, well-defined role, and that focus produces better output than asking a general-purpose assistant to “just do the whole thing.” It’s the same plan-first discipline I cover in the tech-lead pattern: the orchestrator plans and delegates, it doesn’t execute.
Sub-agents for parallel work
Some tasks can run in parallel. When they can, I use sub-agents.
A typical scenario: I’m doing a full SEO audit for a client. There are three distinct pieces, keyword research, competitor analysis, technical on-page audit. None depends on the other being done first. I spin up three agents simultaneously, each with its own focused brief. They run concurrently, and I review the combined output when they’re done.
This is probably the biggest productivity gain in my workflow. For a task that would have taken three sequential hours, I’m waiting forty-five minutes with agents running in parallel.
I do the same for content production. If I have five blog articles to write and none shares a topic or interlinking dependency, I’ll run five content-writer agents simultaneously, each working from its own brief. They all save to the correct output paths and I review them in sequence.
Where I’m careful is with tasks that DO have dependencies. If I’m doing keyword research that will inform content briefs that will inform articles, those steps have to run sequentially. Running a content agent before the keyword research is done produces weaker content; it’s working without the data it needs. I made this mistake a few times early on. Now I’m explicit about dependencies in every multi-step task.
A note on cost: sub-agent setups use measurably more tokens than a single-agent session. Anthropic’s research on one multi-agent research system reported individual agents using roughly 4x the tokens of a plain chat turn and full multi-agent runs roughly 15x, but that is not a fixed Claude Code multiplier. Agent Teams cost scales with the number of active teammates, the models they use, their context, and how long they run. The parallelism is worth it for independent work, but watch the meter and shut down teammates that have finished. I go deeper on running parallel sessions well, worktrees, when to isolate, when to converge, in session craft.
The memory system
The other half of keeping context across sessions is the memory system.
Two things sit under that label, and they do different jobs.
The first is Claude Code’s own auto-memory, which shipped natively earlier this year. It stores at ~/.claude/projects/<project>/memory/MEMORY.md and Claude writes to it itself based on corrections, preferences, and patterns it picks up during sessions. No setup. It’s per-project and doesn’t leak across clients, which is the right scope for that kind of working context.
The second is a memory vault plugin I built for cross-project knowledge, the lessons that need to travel between clients. GRDB’s DatabasePool gives concurrent reads. SwiftUI alert bindings can’t use .constant(). DataForSEO’s on-page tools return cleaner HTML metadata than WebFetch. When I discover something like that on a client project and expect to need it on an unrelated one, I capture it to the vault. The next session, on any project, the knowledge is available. I wrote about the design and rationale here.
Campaign progress lives in TRACKER files separately from both. Each campaign has a TRACKER.md at CLIENT/CAMPAIGN/TRACKER.md. Every task is a row with a status. When a task is done, I update the status. When a session ends, I update the DASHBOARD.
The system sounds like overhead. It isn’t. Five minutes per session to maintain. In return, near-perfect continuity across sessions and clients, without relying on Claude to “remember” things it won’t.
MCP integrations and CLI tools
The DataForSEO integration is the one I use most heavily in marketing work.
When the SEO optimizer or content writer needs keyword data, the call goes out from within the session. Search volume, keyword difficulty, SERP analysis, competitor ranked keywords, backlink profiles, all fetched live, without me copying data from another browser tab into a prompt.
A typical keyword research flow: I ask the market-research skill to pull keyword data for a new topic. It fetches real search volume and difficulty metrics, analyses the SERP composition, writes a brief with validated keyword targets. The whole thing happens in the session. No browser context-switch. No manually entering numbers.
The quality difference this produces in SEO work is significant. Early on, I was feeding Claude keyword data I’d pulled manually from various tools, and inevitably some of it was stale or miscounted. Now the data is live, consistent, and right there in the context window.
A note on the MCP-vs-CLI question: for services with a good CLI (gh, aws, psql, my own dfs and gsc Rust tools), I prefer the CLI. CLI tools are leaner: they produce exactly the output you ask for. Claude Code now defers MCP tool definitions through tool search, so the standing cost is smaller than it once was. I keep MCP for services where structured tool integration earns the cost.
I also have the Gmail MCP connected for client communication workflows, but that’s a separate topic.
What works brilliantly
Multi-file understanding. This is Claude Code’s single greatest strength for my work. I can say “refactor the internal linking across all 24 articles in this campaign” and it will read all 24 files, understand how they relate to each other, and make consistent changes. This would take me hours manually. Claude does it in one session, holding the full picture in context.
Following complex project-specific rules. Every client has a long list of specific requirements:
- naming conventions
- brand language rules
- pricing that varies by course level
- URL patterns
- things that must never be written a certain way I put it in the
CLAUDE.mdand the relevant reference files. Claude follows it. Not perfectly, more on that below, but reliably enough that I trust it to write client-ready copy without constant spot-checking.
Technical SEO work. The combination of DataForSEO, the seo-optimizer skill, and Claude’s ability to read a page’s source HTML means I can do a thorough on-page audit in a fraction of the time it used to take. I ran a full site-wide audit recently, 426 keywords analysed, live SERP data for 8 priority keywords, competitor benchmarking across four money pages, in a single session.
Generating structured output at scale. Tracking files, briefs, campaign plans, content calendars, anything that needs consistent structure produced repeatedly. Claude is better at this than any template I’ve tried to maintain manually.
What doesn’t work yet
I want to be honest about this because most Claude Code tutorials skip it.
Context limits on very large projects. When a campaign has accumulated dozens of files, research docs, briefs, articles, reviews, tracker entries, the context window starts to strain. Claude can read everything, but the further back a file is in the context, the more likely it is to be underweighted. I’ve had sessions where Claude loses track of a specific rule that was set in an earlier file, then corrects itself when I point it out. The fix is keeping CLAUDE.md lean (around 100 lines) and putting specific rules in targeted reference files rather than burying them in general docs. Still a limitation you need to account for.
Cost at scale. Running parallel agents for large tasks, processing long documents, doing iterative SEO audits adds up. The value is clear enough that I don’t track cost religiously, but it’s something to model before scaling. If you’re billing by the hour, the cost is easy to absorb. If you’re on flat-fee retainers, you need to know your usage patterns before you burn through budget.
Occasional wrong decisions. Claude will sometimes make a call I disagree with, a heading structure that buries the lead, a recommendation that doesn’t fit the client’s specific situation, a technical SEO decision that’s generically correct but wrong for this particular site. It happens more often on tasks where I’ve given a broad objective rather than a specific brief. The solution is to be more directive up front, but that sometimes feels like it defeats the purpose. I’ve settled on a rule: for anything that touches client-facing output, I review before it ships. I don’t auto-approve.
When you’re moving faster than the rules. Sometimes a client situation changes mid-project and the CLAUDE.md hasn’t been updated yet. Claude will confidently follow the old rules. This is my fault, not Claude’s. Keeping the context files current is a discipline you have to maintain.
Tips from daily use
Write CLAUDE.md before you do anything else. The 20 minutes you spend writing a thorough one for a new client pays back in every session that follows. Don’t skip it.
Be specific in your task briefs. “Write an SEO article about counselling” produces mediocre output. “Write a 2,000-word pillar article targeting ‘diploma of counselling’ (8,990/mo, KD 46), following the brief in briefs/01-pillar.md, saving to content/diploma-counselling.md” produces something you can use.
Use the TRACKER to pick up tasks, not your memory. Don’t rely on remembering where you are. Write it down. Future-you will thank present-you, especially when you come back after three days on another client.
Keep your skills narrow. If you give a skill too broad a remit, it starts making strategic judgements it shouldn’t. The content writer should write. The strategist should plan. The SEO optimizer should optimise. The cleaner the role separation, the better each one performs.
Run parallel agents for independent tasks. If tasks don’t depend on each other, there’s no reason to run them sequentially. The parallel execution is one of the biggest time savers.
Override when you need to. Claude Code isn’t infallible. When it makes a call you disagree with, say so. “Don’t do it that way, here’s why” works. The model takes corrections well.
Read the output. This sounds obvious, but I’ve seen people treat AI output as final. It isn’t. Read what comes out, especially in the early sessions with a new client or a new type of task. The mistakes are usually in the details.
The bigger picture
What Claude Code has given me isn’t automation. It’s capacity. I can manage six active client campaigns simultaneously without dropping quality or working more hours, because the system handles the parts that used to eat my time:
- context reconstruction
- structure
- first drafts
- research collation
- tracking
The creative and strategic judgements are still mine. Whether a campaign strategy makes sense. Whether a piece of content captures the client’s voice. Whether an SEO recommendation is right for this particular site at this particular moment. Those are calls I make. Claude does the execution once I’ve set the direction.
If you’re a CTO or technical consultant managing multiple concurrent projects and you haven’t built a setup like this yet, the investment is a few days of config and a week of refining the workflow. After that, it pays back continuously.
If you want to know more about how I help organisations build workflows like this one, you can read more about my fractional CTO services.
Related reading
- Claude vs ChatGPT: a practitioner’s honest take
- Top 10 ways to optimise Claude Code token usage
- Claude Code for the full stack: marketing, DevOps, and beyond code
Common questions
How do you manage multiple client projects with Claude Code?
One directory structure per client, a CLAUDE.md per project holding identity and house rules, custom skills for repeated work, and a DASHBOARD file I open first each day. The structure is what lets me switch between six clients without losing context or mixing one client’s conventions into another’s.
What actually ships versus what is just setup?
The parts that ship are the CLAUDE.md files, a handful of custom skills and sub-agents for repeatable work, and the daily DASHBOARD habit. Most of the elaborate configuration people build is overhead; I keep only what prevents a recurring mistake or saves real time.
What does your daily Claude Code workflow look like?
I start from the DASHBOARD to see the state across clients, pick the priority, then work in the relevant project with its CLAUDE.md loaded and lean on skills and sub-agents for the repeated parts. The workflow is built around switching context cleanly, not around any single clever prompt.