Building a personal chief-of-staff AI on Claude Routines

You probably already use AI tools at work. None of them quite do this job. Here's the gap, drawn plainly:

What you actually want, if you're trying to operate at a senior level without a human one, briefs you before the day starts with the day's through-line and biggest risk; checks in mid-day when something has shifted; debriefs you at the end with a retrospective, a coaching score, and one specific note for tomorrow; and responds within the hour when you post a question or ask for an action.

Built right, that costs roughly zero infrastructure and lives on a model plan you may already have.

Two halves, cleanly separated. One holds the personality and rules; the other is the engine that runs them on a schedule.

Brain. A GitHub repo — version-controlled folder of files — containing markdown documents that describe persona, voice, format conventions, and the operator's working context. Editable. Diffable. The same repo is referenced by every routine, so a single edit to chief-of-staff.md propagates to every brief on the next fire.

Runtime. Anthropic's Routines feature inside claude.ai. A Routine entry has four parts: a schedule (or external trigger), a model choice, a connector list (Slack, Calendar, Gmail, Notion, GitHub — connectors are the authenticated bridges that let Claude read and write in those tools), and a small Instructions textarea. No server, no deployment, no continuous-integration pipeline to maintain.

That Instructions textarea stays deliberately thin. It says, in effect, "read these files from the repo and execute the spec." Claude reads them fresh on every fire. Implication: you maintain the brain in git, not in the textarea. Voice updates, format changes, new section conventions — all of it ships through commits, not through clicking through Routine entries one by one.

Six files make up the brain, split into two groups by what they track. Four describe who the assistant is; two record what it's learning about you.

The four files in persona/ form the persona stack:

Voice — the canonical voice the assistant speaks in. A blend of postures, encoded as rules: operator-first practicality, POV-first directness, declarative confidence, calm technical confidence over hedge-everything reporting, dry observational humour. Pick the postures you want; encode them as rules with named "sounds like / doesn't sound like" examples. Never changes.

Identity — the operator (you). Career, expertise, working style, side projects. Survives company moves. Edited only when something material in your career or domain shifts.

Chassis — format rules, day's rhythm, multi-day continuity, coaching stance, the draft-react protocol (covered below), confidence labelling on inferred claims, attribution rule (parameterised — operator picks brand attribution or none), what to never do (sycophancy, AI tells, padded prose). Almost never changes.

Context — current employer, output channel, and self-populating sections: standing priorities, people whose mention always surfaces, recurring projects, open threads. Reset on company moves.

The two files the assistant writes to over time form the memory layers — the bit that lets the system learn from you instead of starting flat each day:

Interests filter (persona/interests.md) — two lists the system populates from your feedback: Surface (topics, channels, people you actively want flagged) and Don't surface (themes filtered out). Say "don't tell me about vendor stuff" in the channel and the assistant appends to the list, commits, and acknowledges. Critical signals (CEO mentions, paying-customer escalations, imminent meetings) bypass the filter. Weekly review prunes stale entries.

Decision log (decisions/log.md) — append-only chronological record of decisions: context, call, reasoning, outcome. Open Threads tracks what's open; this file tracks what's closed. Six months from now you can ask "what did we decide about X?" and get the actual answer back. Routines write entries when threads close with outcomes; morning brief reads entries when meeting prep needs prior decision context.

Portability still holds. When you change jobs, you edit Context, wipe the self-populating sections, and reset the interests filter. Voice, identity, chassis, and decision log persist. The architecture isn't coupled to one company.

The system runs on five Routine entries — five separately scheduled jobs, each with its own time and purpose. They read the same persona files, but the spec each one executes is different. The point of having five rather than one is that each looks at the day from a different angle, and the angles don't overlap.

Morning brief — daily, weekday early. The forward read of the day. Opening paragraph carries the through-line and biggest risk. Sections: The day (calendar with one-line prep notes per meeting), Overnight (signals worth flagging from email and Slack), Pending (what's in flight and at risk, including aged followups and decisions overdue), Yesterday's read (productivity coaching from last night's end-of-day reply, when there's a pattern worth naming), Looking ahead (forward calendar friction), Questions. The brief also drafts today's project work blocks — 60–90 minute focus blocks for the day's active projects — and surfaces them as 📝 DRAFT · calendar event · work block posts you approve with a ✅ react.

Channel pulse — hourly during the workday. The interactive layer. Reads your messages, processes draft reactions, scans the workspace for things you'd care about, briefs upcoming meetings, drafts replies for unanswered DMs, surfaces interesting signals. Six things on each fire, most of them silent on a quiet hour. The single most differentiated piece of the architecture — covered in detail below.

Midday pulse — daily, weekday early afternoon. Drift check against the morning brief. Stays silent on most days; fires when something has materially shifted (cancelled meeting, urgent inbound, a slipping deadline now visible, a draft that's been pending half a day).

Evening debrief — daily, weekday early evening. Retrospective, coaching layer, and end-of-day reconciliation in one routine. Coaching is a 1–10 score on a dimension you pick (communication, decisiveness, hill-choice, follow-up integrity, focus discipline, energy management — pick one), grounded in real examples from today, with a calibration paragraph and a colour-coded bar chart. Reconciliation is the day's closing loop: every commitment you had today (work blocks, aged followups, pending decisions, meeting deliverables) gets listed and annotated with what the signals say happened — "looks shipped: 4 commits during the block" / "looks slipped: 22 min in #general, no project signal" / "status unclear, you tell me" — and you confirm, correct, or fill in. Free-text replies in thread. Tomorrow's morning brief uses your reply to surface productivity coaching when a pattern warrants it.

Weekly review — Sunday evening. Strategic frame for the week. Communication-rating trend across the five days. Priority-alignment audit (green/amber/red on each standing priority). Org-chart refresh — the People list in Context kept current via Slack signal mining. System hygiene — pruning the interests filter and tracking the draft hit rate. Cross-time pattern detection across the past 8 weeks: trend on the rating, priority drift, recurring stalling, decision velocity, person cadence shifts. Week ahead: big rocks, calendar conflicts, deadlines on the horizon.

Five vantages — forward, interactive, course-correction, retrospective, strategic — and they don't overlap. If a section appears in two routines, one of them is doing the wrong job. Duplication is a design failure; keeping each routine's vantage distinct is what makes the system feel coherent rather than noisy.

Channel pulse fires every hour during the workday. Six things happen on each fire, in order. Most fires do none of them and exit silently — that's the design.

1. Process pending drafts. Scan recent 📝 DRAFT posts for ✅ / ❌ / thread reply, and execute / drop / redraft accordingly. The draft-react protocol is the load-bearing mechanism — covered separately below.

2. Reply or take action on your most recent unanswered message in the output channel. Authorisation is full-power for the channel — the assistant executes whatever you explicitly ask, using whichever connector applies. Outbound communication still goes through the draft-react gate; reads, summaries, internal repo writes don't.

3. Brief upcoming meetings starting in the next 60 minutes. Format: a header (📋 MEETING PREP · 14:30 Anna 1:1) followed by last touch, likely raise, recommended position, open threads, and prior decisions involving the attendee. For external attendees (anyone outside your workspace), an additional 🔎 Background sub-section pulled from Gmail history, Slack mentions, past meetings, and HubSpot — so you don't walk in cold.

4. Draft replies for pending DMs workspace-wide. Any direct message that's been sitting more than 60 minutes without a reply gets a 📝 DRAFT reply surfaced in the channel. Bots and clearly automated senders are skipped. Nothing sends until you ✅.

5. Surface interesting workspace signals. Reads channels you're a member of, applies the interests filter, surfaces 0–3 items per fire as 👀 WORTH KNOWING posts. The bar: matches a Surface entry, or the kind of thing a sharp chief of staff would flag (strategic decision being made without you, paying-customer escalation, leadership thread on a Standing priority). Restraint is the design.

6. Update memory layers. Open threads in Context, interests filter from your feedback, decision log when threads close with outcomes.

The non-obvious correctness loop: the read scope is "your messages newer than my most recent post in the channel." Once the assistant has acted and posted a confirmation, that confirmation becomes the new "most recent post," and the next fire doesn't re-execute the same request. The reply itself is the dedup mechanism.

Skip mechanism. Post "skip pulse" in the channel. The assistant appends an active open thread to the Context file ("channel_pulse skipped through <date>"). Every subsequent fire reads the thread first; if active, exits silently. Resumes when you close the thread or the date passes. The mute is durable across fires without requiring any external state.

This is the chassis-level rule that makes the system trustable. An AI that sends real emails and creates real calendar events on your behalf without asking is a non-starter — too much downside on too few wins. Draft-react flips the trade: the assistant does the proactive work of writing the message or building the event, then waits for a single emoji react before anything actually leaves the building.

Three categories of work flow through it: outbound communication (emails, DMs, channel posts outside the operator channel, calendar invites, shared-doc comments), calendar event creation (prep blocks before high-stakes meetings, project work blocks for Standing priorities), and any record creation visible to others.

Mechanically:

1. The routine posts a 📝 DRAFT in the operator channel — proposed text, recipient, route. The post ends with: → React ✅ to send · ❌ to drop · or reply with edits.

2. You react on the draft post. ✅ executes (sends the email, creates the event, etc.); ❌ drops it; a thread reply with text triggers a redraft incorporating your changes.

3. After execution, the draft message is edited in place to ✅ SENT · summary · link. The audit trail stays visible in the channel without spawning extra messages.

4. Pending drafts persist. Every routine that fires after a draft is created surfaces a one-line callout: 📝 2 drafts pending — DM to Anna (1h), prep block tomorrow (3h). Drafts older than 24h get an explicit nudge. Drafts older than 48h get coaching tone. Letting drafts pile up is a coaching-worthy pattern, not a neutral one.

Three kinds of autonomous drafting fire without you asking:

One additional shape fires when a draft is contentious: 🪞 STRESS-TEST. When a draft is dissent, pushback, or a difficult message, the assistant follows it with a threaded post naming how the recipient will likely respond (steel-manned, not strawmanned), the strongest counter to your position, and one reframe that captures your intent without the failure mode. The stress-test never blocks send; it's information, not a gate. You can ✅ the parent draft as-is, redraft based on the stress-test, or ❌ drop. This is the sharpest coaching move in the system — most AI assistants tell you what you want to hear; the stress-test offers the recipient's steel-manned response instead.

Most operators run two parallel systems: a calendar for meetings and a todo list for everything else. The two never reconcile. Tasks accumulate on the list while the calendar fills with meetings, and at the end of the week you can't tell which work actually got done versus which was dragged forward another seven days. This system removes the second list entirely. The calendar is the source of truth for what you're doing and what you intend to do — not in the repo, not in Notion, not in a sidecar database. Open threads track the intent across days; the calendar carries the commitment for today.

Morning brief and channel pulse draft 1–3 focus blocks per day for active Standing priorities and in-flight Open threads. Title format is always Focus: <project name> — Focus: Comet Sparkle key check, not Focus alone. Default duration: 60–90 minutes for focused work, 30 minutes for quick wins, 120 for genuine deep work. Blocks are placed in existing calendar gaps and respect decompression rules (15-minute minimum between meetings up to 30 minutes long, 30 minutes between meetings of an hour or more). Cap at 2–3 blocks per day; over-scheduling is the failure mode.

Same draft-react flow. Every block is surfaced as a 📝 DRAFT · calendar event · work block post; ✅ adds to the calendar, ❌ drops, thread reply redrafts (move, resize, relabel). Nothing auto-creates.

Why this works as task tracking. Every block is a commitment in time, not a vague intent. At end-of-day, the question "did the work happen?" is answerable by checking whether the block was used — Granola transcripts, Slack activity, GitHub commits during the block's window — not by re-reading a todo list. Tasks that don't get a block don't get done. Work that gets done without a block was unplanned, which is itself signal.

The whole system would leak without a closing loop. Drafts get approved or dropped, blocks get used or skipped, decisions get made or deferred — and unless something asks "so, what actually happened today?", the next morning starts blind. The evening debrief ends with a structured reconciliation prompt that turns the day's calendar audit into the input for tomorrow's coaching. Format:

📋 END-OF-DAY CHECK

Today's commitments — confirm, correct, or fill in. Free text fine:

1. Focus: Comet Sparkle key check (14:00–15:30) — signal: 4 commits during the block. Looks shipped.
2. Focus: Q2 OKR pre-read for Anna (10:00–11:30) — no observable activity; 22 min in #general. Status?
3. Followup: Maya re: Whering v2 onboarding — owed 4 days; yesterday's EOD said this would land today. Did it?
4. Decision pending: Comet release timing (Wed vs Thu) — logged 3 days ago, no movement. Made the call?

Plus:

A. What got done today that wasn't on the list?
B. What's carrying to tomorrow?
C. Anything I should pencil into tomorrow's calendar?

Tomorrow morning's brief will include productivity coaching based on your reply.

That list comes from today's work blocks, aged Open Threads, yesterday's "carrying to tomorrow" items, and meeting commitments surfaced from Granola/Gemini transcripts. Each commitment is annotated with the signal read — first guess at whether it shipped — and you confirm, correct, or fill in. Free-text replies are fine; the structure makes the reply fast, not constrained.

Whichever routine fires next processes your reply: shipped items become decision log entries and close Open Threads (with confidence labels where signal didn't confirm independently); carrying items become category-3 or category-4 Open Threads that drive tomorrow's work block drafts; calendar penciling items get drafted as 📝 DRAFT · calendar event posts in the morning brief or the next channel pulse.

Tomorrow's morning brief surfaces a 🎯 Yesterday's read section when a pattern warrants it — same item slipping repeatedly, blocks being replaced with reactive Slack, growing carry-over backlog, decisions repeatedly deferred. Tone is observational. Bar to clear: a sharp colleague who saw the pattern would actually say this. Otherwise, skip the section. Manufactured coaching is its own failure mode.

All five routines run on Claude Opus 4.7 with 1M context. (Models come in tiers — Opus is the most capable; the 1M context refers to how much text the model can hold at once, roughly 750,000 words.) An earlier hybrid strategy used the cheaper Sonnet model for the briefs and reserved Opus for the debrief only. Saved a little on token cost. Introduced subtle voice drift between routines — morning brief sounded slightly different from evening debrief. Uniform Opus across all five fixes that. Voice stays consistent, the 1M context window pays off in the workspace-wide scan and 8-week pattern detection, and the Max plan absorbs the cost.

Binding constraint isn't price; it's the 25 routine runs per day cap on the Max plan. Default rhythm — 4 daily briefs plus 13 hourly channel pulse fires across the workday plus 1 weekly review on Sunday — comes to roughly 16 fires per weekday peak, comfortably inside the cap with about 9 fires/day spare for any future API-triggered events.

If you want real-time triggering on top of the cron rhythm (Slack events firing the channel pulse via Zapier or Pipedream rather than waiting for the next hour), you have the headroom for it — but plan filters carefully. A trigger that fires on every incoming DM blows the daily cap by lunchtime. Filter to: DMs from humans only, mentions with explicit asks, calendar booking requests. Plus a debounce of one fire per five minutes per trigger type.

The full rollout takes a few hours, max. Claude Code (Anthropic's command-line coding tool) does the heavy file-writing via the bootstrap prompt below; the rest is review, commit, and clicking through Routine entries in claude.ai. Don't hand-write the persona and routine specs — the architecture has enough surface area that a manual first pass loses to an interview-driven one.

1. Create the GitHub repo. Private, empty, named however you want. The folder structure (persona/, routines/, README.md) gets generated by Claude Code in the next step.

2. Open Claude Code at the repo root in a terminal. Paste the bootstrap prompt from the section below. Answer the five customisation questions thoughtfully — Claude Code is told to push back on vague answers, but specific answers are what produce the version you'll actually use. Voice, identity, output channel, coaching dimension, connectors. About 20 minutes if you're ready with the answers.

3. Review what Claude Code generated. Walk the persona files first — voice, identity, chassis, context. These are the brain; everything else reads them. Edit anything that doesn't sound like you. The routine specs and .txt setup files come from the chassis, so getting the chassis right pays off everywhere else.

4. Commit and push to GitHub. Claude Code can run the git commands directly from the same session if you ask it to.

5. Authorise the GitHub App on the repo. claude.ai needs read access; the assistant also writes back to the Context file, so write access is needed too — scoped to this repo only. Set the GitHub App's repository access to include it.

6. Create the Routine entries in claude.ai → Agents → Routines → Create. One per routine. Open the corresponding .txt file from the repo and copy field-by-field: name, repository, trigger, cron expression in UTC, model, environment, connectors. Paste the Instructions textarea content exactly. Five Routines = roughly 25 minutes of clicking.

7. Smoke-test each one with a manual run from the Routine UI. Read the output in your channel. If voice or format drifts, edit the chassis file, push, manual-run again. The textarea doesn't need re-pasting — Claude reads the chassis file fresh on every fire.

8. Configure your output channel. Mobile notifications on so the morning brief lands somewhere you'll see it. The first scheduled fire tomorrow morning is the real validation.

Six outcomes that show up consistently after two weeks of running the full system:

The thing it doesn't do: replace your judgement. The system surfaces, sequences, drafts, and reconciles. You still decide. The chief-of-staff metaphor is exactly right — they don't do your job; they make it possible for you to do it well.

Open a fresh Claude Code session in an empty directory you want to use for the repo, then paste the prompt below. Claude Code clones the template, walks you through a six-question interview, fills in the operator-specific files, and gives you the claude.ai setup checklist.

I want you to help me set up a personal chief-of-staff AI using Anthropic's Routines feature, following the architecture documented at https://yourorbit.team/guides/personal-chief-of-staff-claude-routines.

First, clone the template repo into the current working directory:

  git clone https://github.com/justinwilliames/claude-routines-chief-of-staff.git .

The chassis (persona/chief-of-staff.md), routine specs (routines/*.md and .txt), interests filter, and decision log scaffold are all in place. You'll be customising three operator-specific files (persona/orbit.md for voice, persona/about-me.md for identity, persona/context.md for current employer and output channel) plus one chassis tweak (Rule 2 in persona/chief-of-staff.md) for brand attribution.

Read the existing template files first to understand the structure. Then ask me six questions:

1. Identity — my name, role, employer, timezone, and the domains where I have deep expertise. This populates persona/about-me.md.
2. Voice — five reference authors or styles I want the assistant to blend (tone only, not their content). Suggest a default mix if I'm unsure, and let me swap any of them.
3. Output channel — where the assistant posts (a Slack channel, a Teams channel, an email thread, a Notion daily-notes page). The name lives in persona/context.md and every routine reads it from there.
4. Coaching dimension — the blind spot the evening debrief grades me on daily. Examples: communication, decisiveness, hill-choice, follow-up integrity, focus discipline, energy management. Pick one. Don't run multiple at once.
5. Connectors — which integrations I have authenticated in claude.ai (Slack, Calendar, Gmail, Notion, GitHub, Drive, others). The channel_pulse routine uses all of them; the briefs use a narrower subset.
6. Brand attribution — what (if anything) should outbound messages end with? Options: an operator-only line such as "Sarah's AI Assistant", an operator-plus-brand line such as "Sarah's AI Assistant, Powered by my-brand", or blank (platform attribution alone — the Claude Slack integration auto-appends 'Sent using @Claude'). Whichever I pick, never write the platform's tag yourself.

Once you have my answers, update the operator-specific files plus Rule 2 in persona/chief-of-staff.md. Don't touch the chassis architecture or routine specs unless something genuinely needs adjustment for my setup — those files are the constants.

After the customisation, ask me where to push the customised template (a private GitHub repo I'll create) and initialise the new remote. Push.

Then give me an ordered checklist of what to do in claude.ai: create the five Routine entries one by one, copy values from the .txt files (Name, Repository, Trigger, Cron expression in UTC mapped from my timezone, Model — Opus 4.7 with 1M context for all five — Environment, Connectors, full Instructions textarea content), smoke-test each with a manual run, watch the first morning brief tomorrow.

Push back on me if my answers are vague. Generic answers produce a generic system; specific answers produce the version I'll actually use.

Why the questions matter: this architecture only earns its keep when voice, identity, coaching dimension, and working context are tuned to one specific operator. A bootstrap that skips the questions produces a working system you won't use; a bootstrap that asks the questions produces one you will.

This isn't a free lunch. Four trade-offs worth landing before you commit:

It only works in companies that allow third-party AI integrations. The whole architecture depends on Anthropic's connectors authenticating against your work tools — Slack, Calendar, Gmail, Notion. Many enterprises restrict this. If yours does, you have two choices: deploy in your personal account with personal-workspace tools (loses the work signal), or wait for IT approval (timeline unknown). Worth checking before you build.

The draft-react flow needs you to actually clear drafts. The protocol prevents auto-send, which is the right safety call — but it means every outbound action waits on your ✅ or ❌. If you let drafts pile up, the system surfaces them with escalating coaching tone (24h pending = explicit nudge in the brief; 48h = moves to Pending with coaching). This is intentional friction, but the system is less useful if you treat the channel as inbox-zero-optional. Plan for two minutes a day clearing the backlog.

Voice drift is on you. No automated voice regression test catches subtle drift the way reading tomorrow's morning brief does. The discipline is: when a brief lands wrong — wrong tone, wrong shape, wrong omission — fix the chassis file the same day. The system is only as sharp as the most recent commit.

The run quota is a real ceiling. 25 routine runs per day on the Max plan, ~16 used by the default cron rhythm, ~9 spare. Plenty for the system as-built; tight if you wire up real-time triggers via Zapier or Pipedream without filtering carefully. Filter trigger events to high-value only — humans not bots, mentions with explicit asks, calendar requests — and add a debounce. Otherwise the cap blows by lunchtime.

None of these is a deal-breaker; all four are worth knowing about before you start building.