Setup sequence
The order matters. Each phase builds on the previous and gives you usable output as soon as possible — no waiting for the slowest dependency to unblock the whole project.
The total time is roughly seven to nine hours of work spread across two weeks, not counting waiting time for the IT ticket if you’re going the Microsoft Graph route.
Each phase ends with a verification check. Don’t skip them — they catch silent failures (a skill that loaded but isn’t being invoked, a Python install that worked but didn’t end up on the right Python path) much faster than discovering the problem mid-workflow.
Phase 1 — Foundation (Day 1, ~1 hour)
Section titled “Phase 1 — Foundation (Day 1, ~1 hour)”Create the folder structure
Section titled “Create the folder structure”mkdir -p ~/command-centre/{context,workflows,scripts,templates,outputs/{briefs,drafts,decks}}cd ~/command-centreInstall the document-creation skills at user level
Section titled “Install the document-creation skills at user level”The xlsx and pptx skills from Anthropic’s skills repo handle Excel and PowerPoint generation natively. They install once at user level and are available to every Claude Code project on your machine — including the command centre and anything else you build later.
# Create the user-level skills directory if it doesn't existmkdir -p ~/.claude/skills
# Clone the Anthropic skills repo to a temporary locationgit clone https://github.com/anthropics/skills.git /tmp/anthropic-skills
# Copy just the xlsx and pptx skillscp -r /tmp/anthropic-skills/skills/xlsx ~/.claude/skills/cp -r /tmp/anthropic-skills/skills/pptx ~/.claude/skills/
# Clean uprm -rf /tmp/anthropic-skillsIf git clone is blocked at your tenant, download the repo as a ZIP from GitHub via browser and extract the two skill folders manually into ~/.claude/skills/.
For why these skills belong at user level rather than inside the command-centre folder, see section 23 (How Claude Code finds your config).
Create CLAUDE.md and README.md
Section titled “Create CLAUDE.md and README.md”Create CLAUDE.md using the template from section 25. Customise the role line.
Create README.md using the template from section 26. Most fields you’ll fill in later — that’s fine.
Verify the foundation
Section titled “Verify the foundation”Three checks before moving on.
Skill detection works from anywhere. Run from your home folder, not the command centre:
cd ~claudeAsk: “What skills do you have available?”
The response should list xlsx and pptx. If they don’t appear, the skill folders aren’t in the right place — check that each contains a SKILL.md file at its root.
CLAUDE.md loads from the command centre. Exit Claude Code, then:
cd ~/command-centreclaudeAsk: “What do you know about this folder?”
The response should reference your CLAUDE.md content — your role, the context files it expects, the default behaviours. If it doesn’t, CLAUDE.md isn’t being detected. Confirm the filename is exactly CLAUDE.md (case matters on some filesystems) and it sits at the folder root.
Both layers load together. While still inside the command centre, ask: “What skills do you have available?”
The xlsx and pptx skills should still be listed. User-level skills persist regardless of which folder you’re in — that’s the test that confirms the two layers are cooperating correctly.
Phase 2 — Context (Days 2–5, ~3.5 hours total)
Section titled “Phase 2 — Context (Days 2–5, ~3.5 hours total)”The order matters: easier files first to build momentum, hardest files last.
Write context/role.md (15 minutes). Straightforward — your title, manager, scope. Fill from memory.
Write context/projects.md (20 minutes). List your top 5–8 active workstreams with one-line state each.
Write context/people.md (45 minutes). Most time-consuming because the list is long. Don’t try for completeness — start with internal team, key leadership, top 3–5 client contacts. Add others as they come up.
Write context/priorities.md (45 minutes). The high-leverage file. Be honest about your real triage rules, not aspirational ones.
Write context/voice.md (90 minutes). Block dedicated time. Find 5–6 real sent emails across different contexts. Sanitise sensitive details. Paste them in. This is the file with the highest impact on draft quality.
Write context/anti-voice.md (30 minutes initially, grows over time). Start with the template provided. Add your own pet peeves. This file matters more than it looks because it filters every piece of writing Claude produces, not just drafts in your voice.
Verify the context layer
Section titled “Verify the context layer”Run claude in the command centre folder and ask: “Summarise what you know about me from the context files.”
The response should pull from all six files — your role, current projects, key people, priority rules, voice and anti-voice guidance. If anything is missing or vague, the relevant file needs more content. This is the moment to catch gaps before they bite in real workflows.
Phase 3 — First working tool (Day 6–7, ~2 hours)
Section titled “Phase 3 — First working tool (Day 6–7, ~2 hours)”Install Python dependencies
Section titled “Install Python dependencies”python3 --version # should be 3.11+pip install python-pptx openpyxlIf pip is blocked at your tenant, check for an internal package mirror or use a personal machine. The skills installed in Phase 1 invoke these Python packages under the hood, so they need to be available.
Set up the deck pipeline
Section titled “Set up the deck pipeline”Copy your brand template to templates/brand_template.pptx.
Inspect the template with a one-off script Claude Code can write — list the layouts and placeholder indices. Update build_deck.py accordingly.
Create scripts/build_deck.py using the template from section 34.
Create templates/brief_format.md (you’ll use this in Phase 5, but it’s quick to do now).
Create workflows/deck.md — a simplified workflow file following the brief workflow shape from section 33, but for the deck task.
Verify the deck pipeline
Section titled “Verify the deck pipeline”Two tests.
Skill invocation test. In Claude Code, ask: “Build a simple 3-slide PowerPoint deck about [a topic from your work]. Save to outputs/decks/test-deck.pptx.”
Watch the response. Claude should reference the pptx skill being loaded (the skill name appears in the tool/context output). The file should land in outputs/decks/. Open it in PowerPoint and confirm three slides exist with your content.
If the skill loaded but no file was produced, Python dependencies likely aren’t reachable from the skill’s execution context. If the skill didn’t load at all, check Phase 1 skill verification again.
Brand template round-trip. Take a markdown outline of an existing deck of yours, run build_deck.py, open the output in PowerPoint. Confirm the brand layouts are preserved (placeholder positions, fonts, colours). If anything looks off, the placeholder indices in build_deck.py likely need updating — your brand template has custom layouts that differ from defaults.
Phase 4 — Outlook decision (Day 8–14)
Section titled “Phase 4 — Outlook decision (Day 8–14)”File the IT ticket for Microsoft Graph API app registration with delegated permissions: Mail.Read, Mail.ReadWrite, Mail.Send, Calendars.Read. Expect days to weeks for response.
In parallel, build the AppleScript fallback. This works today against Outlook for Mac desktop, no IT involvement. Read-only first.
Create scripts/pull_outlook.py using whichever path is unblocked.
Create scripts/save_draft.py using the template from section 34.
Verify the Outlook integration
Section titled “Verify the Outlook integration”Two checks, run them in this order.
Read path. Ask Claude: “Pull today’s calendar from Outlook and list the meetings.”
Compare the response to what’s actually in your Outlook calendar. Meeting count, times, and titles should match. If they don’t, the read path is broken — usually an auth issue with Graph, or AppleScript permissions not granted to the terminal.
Draft path. Ask Claude: “Draft a one-sentence test email to me, save as a draft, and report the file path.”
The .eml file should land in outputs/drafts/. Open it in Outlook (double-click on Mac) and confirm it opens as a draft, not a sent email. This is the test that confirms drafts are write-only — nothing leaves your machine.
Phase 5 — Brief workflow (Day 15)
Section titled “Phase 5 — Brief workflow (Day 15)”Create workflows/brief.md using the template from section 33.
Run the morning brief. First runs will be rough — note where context is missing, where rules misclassify, where output formatting feels off. Update files accordingly.
Verify the brief workflow
Section titled “Verify the brief workflow”Run “morning brief” and confirm:
- The brief file lands in
outputs/briefs/with today’s date as aYYYY-MM-DD-brief.mdprefix - The brief follows the structure in
templates/brief_format.md - Meeting counts match Outlook, inbox classifications make sense against your
priorities.mdrules - Unknown senders are flagged with the
[unknown sender — flagged for people.md update]format - No fabricated meetings or senders
Once you’ve run it 3–4 times, paste a real good brief into templates/brief_format.md as the example. This anchors future runs better than the synthetic structure alone.
Phase 6 — Reply and triage workflows (Week 3+)
Section titled “Phase 6 — Reply and triage workflows (Week 3+)”Build workflows/reply.md. Wait until voice.md has had a few real client interactions added — fresh examples beat older ones.
Build workflows/triage.md. This composes brief + reply, so leave it last. It pulls inbox, classifies, then for each “Reply” bucket invokes the reply workflow.
Verify the reply workflow
Section titled “Verify the reply workflow”Ask Claude: “Draft a reply to the most recent email from [a real internal peer].”
Open the resulting .eml in Outlook and check:
- It opens as a draft, not sent
- The voice matches your
voice.mdexamples - No banned phrases from
anti-voice.mdappear - The recipient and subject line are correct
- Any uncertain content uses
[NEEDS: ...]placeholders rather than guessed details
Test the same workflow against a senior or external recipient before trusting it for those. The risk model is different — internal peer drafts can be near-zero-edit; senior client drafts need a careful read every time.
Verify the triage workflow
Section titled “Verify the triage workflow”Run “triage my inbox”. Confirm:
- The triage summary follows the brief format
- Each unread email is classified into exactly one bucket
- “Reply today” and “Reply this week” emails have drafts saved to
outputs/drafts/ - “Needs my judgement” items appear at the top with reasoning
- Auto-FYI items are counted but not individually listed
Phase 7 — Aliases and ongoing maintenance
Section titled “Phase 7 — Aliases and ongoing maintenance”Add shell aliases to ~/.zshrc:
alias cc='cd ~/command-centre && claude'alias brief='cd ~/command-centre && claude "run the morning brief"'alias triage='cd ~/command-centre && claude "triage my inbox"'Reload your shell (source ~/.zshrc) and verify each alias works.
Set a monthly calendar reminder to update context files. People change roles, projects shift state, priorities drift. Stale context is the silent killer of these systems.
Set a quarterly reminder for two things: refresh voice.md with recent sent emails, and prune/extend anti-voice.md based on the patterns you’ve actually been editing out of drafts.
Anti-patterns to avoid
Section titled “Anti-patterns to avoid”A few specific failure modes worth naming so you don’t fall into them.
Building everything before using anything. The temptation is to set up the whole structure perfectly before doing real work in it. Resist. Get one workflow working end-to-end (decks) before building the others. You’ll learn what matters and what’s overkill.
Letting CLAUDE.md grow. Every time you discover a new rule, the urge is to add it to CLAUDE.md. Don’t. Add it to the relevant context or workflow file.
Adding workflows speculatively. Only codify a workflow once you’ve done the same task three times manually. Workflows you write before you’ve felt the actual pain are usually wrong about what the pain is.
Trusting drafts blindly. The system can produce a confident-sounding draft to a senior client that’s subtly off-tone. Read every draft to senior or external recipients before sending. Always.
Auto-running the system. Don’t put this on a cron. Run it on demand, when you’re at the keyboard and ready to review outputs.
Skipping verification checks. They feel optional when everything looks like it’s working. The cost of running them is 30 seconds per phase; the cost of finding out at the end of Phase 6 that the skills never actually loaded is a rebuild from Phase 1.
The weekly refinement loop
Section titled “The weekly refinement loop”Maintenance rules tend to fail when they’re vague aspirations. Pin a fifteen-minute slot on Friday afternoon and answer three questions; each one is paired with the follow-up action that closes the loop.
- What did the system miss that I had to discover on my own? → update the relevant context file. The miss usually means a fact about a person, project, or priority isn’t captured yet.
- What did it produce that I had to redo? → fix the workflow or template. The redo usually means the rules in
workflows/*.md(or the prompt template, or the brand template) are missing a constraint. - What new recurring task appeared this week that I should automate next? → draft a new workflow. Once a task has happened three times manually, codifying it is worth the time.
Skip the loop and the system slowly drifts behind what the work actually is. Run it and the gap between “what’s in the files” and “what’s true” stays small.
What success looks like
Section titled “What success looks like”After three to four weeks of use, the morning brief takes 30 seconds to invoke and 2 minutes to read. Deck generation handles 70–80% of the structural work; you finish visuals in PowerPoint. Drafted replies need light editing for senior recipients and near-zero editing for internal peers. Context files have become living documents you update when something changes.
The system that works is the boring one you actually use, not the impressive one that handles edge cases you never hit.