GUIDE
Build a Chief of Staff Agent with Claude Code
Turn Claude Code into a real chief of staff with a starter plugin, optional calendar and inbox integrations, and copy-paste setup prompts.
Most ambitious operators don't need another to-do list app. They need a chief of staff that can scan the calendar, inbox, Slack, backlog, and notes, then tell them what actually matters.
I built a shareable starter for that workflow: a chief-of-staff agent starter you can run with Claude Code, with reusable commands, skills, setup docs, and prompts.
The GitHub Repo
Get The Starter
Repo URL
https://github.com/travisseh/chief-of-staff-plugin-starter
Install Or Update Prompt
Help me install or update this chief-of-staff repo the right way inside Claude Code. Repo: https://github.com/travisseh/chief-of-staff-plugin-starter First ask whether I want: - dev mode with claude --plugin-dir - installed mode through Claude Code's plugin installer / a local marketplace Then: - clone or update the repo at ~/.claude/plugins/chief-of-staff unless I choose a different path - validate the repo with /plugin validate . if available, or at least verify .claude-plugin/plugin.json exists - if I choose dev mode, give me the exact claude --plugin-dir command and explain that it avoids marketplace/cache issues while I personalize the agent - if I choose installed mode, do not edit ~/.claude/plugins/installed_plugins.json manually; use the normal /plugin install or /plugin update flow instead - if commands, skills, agents, or other tracked files changed, remind me installed plugins are cached copies and may need a version bump, update or reinstall, and a Claude Code restart before the new files load At the end, tell me the best first prompt to run next.
For first-time setup and iteration, the cleanest path is usually claude --plugin-dir /path/to/repo. That loads the source repo directly. An installed plugin is a separate cached copy, so cloning alone is not the whole install flow.
What's In The Repo
The repo is a plugin-style starter, not just a long system prompt. It includes daily briefing workflows, comms sweeps, an executive-strategist agent, optional browser-automation errands, local backlog and writing-style skills, setup docs for the integrations that make the whole thing useful, and install guidance that covers the Claude Code plugin cache and update flow.
chief-of-staff-plugin-starter/
├── .claude-plugin/plugin.json
├── CLAUDE.md
├── README.md
├── commands/
│ ├── cos.md
│ ├── brief.md
│ ├── status.md
│ ├── sweep.md
│ └── errand.md
├── agents/
│ └── executive-strategist.md
├── skills/
│ ├── apple-notes/
│ ├── executive-assistant/
│ ├── errands/
│ ├── imessage/
│ ├── linkedin/
│ ├── linkedin-voice/
│ ├── notion-backlog/
│ ├── slack/
│ ├── stripe/
│ └── writing-style/
├── docs/
│ ├── integrations/
│ └── prompts/
└── state/
├── insights.template.md
└── daily/The Prompt To Personalize It
This is the fastest way to turn the starter into your version. It also handles the privacy setup by creating a private state/insights.local.md file and keeping secrets out of tracked files. Open the repo in Claude Code and paste:
Read this repo and help me turn it into my own chief-of-staff system. Read: - README.md - CLAUDE.md - state/insights.template.md - skills/executive-assistant/references/integration-registry.md Then interview me one question at a time to fill in: - my life and work areas - my priority stack - my protected time - my decision rules - my writing style - which integrations I actually want Create state/insights.local.md with my real answers. Treat state/insights.local.md as my private durable context file. Keep daily notes in state/daily/ private and untracked. Do not store tokens, OAuth JSON, API keys, phone numbers, note IDs, or other secrets in tracked files. If I am using an installed plugin instead of claude --plugin-dir, warn me when tracked-file changes may require a version bump, update or reinstall, and a Claude Code restart. Keep shared files reusable unless a template improvement helps everyone.
The Integrations You Can Wire In
You do not need every integration on day one. The starter is modular. Claude should use the tools that are configured and degrade gracefully when something is missing.
Google Calendar
Schedules and event creation. Requires Google OAuth desktop credentials.
Gmail
Inbox scans, thread reads, drafts, and replies. Usually uses the same Google OAuth credentials plus local account tokens.
Slack
Multi-workspace summaries and replies. Requires a user OAuth token per workspace.
Notion
Backlog management. Best via the official Notion MCP and OAuth.
Apple Notes
Personal context and checklists. No API key, just local macOS access.
iMessage
Message awareness and sending. No API key, but macOS-only and needs Full Disk Access.
Browser automation workflow. No API key here, just a logged-in browser session.
The Setup Order I Recommend
- Personalize the memory first. Fill in priorities, protected time, decision rules, and writing style.
- Add read-only integrations. Start with calendar, then inbox, then Slack, then tasks.
- Run a first real brief. Let Claude show you what's missing instead of over-engineering upfront.
- Only then enable send/write actions. Drafting is cheap. Mistakes in public or in someone's inbox are not.
The Prompt To Connect Integrations
Once the memory is personalized, use a second prompt to wire in real systems safely:
Read this repo and help me connect integrations one by one. Rules: - start read-only where possible - use official setup docs from the repo - keep secrets in local config or env vars - verify each integration before moving to the next - if you edit tracked plugin files and I am using an installed plugin rather than claude --plugin-dir, tell me whether I need to bump the plugin version, update or reinstall, and restart Claude Code Setup order: 1. Google Calendar 2. Gmail 3. Slack 4. Notion 5. Apple Notes 6. iMessage 7. LinkedIn browser automation For each integration: - tell me what credential is required - tell me where to click or what command to run - update the integration registry - run one safe verification step
How To Keep It Private
The public repo should never contain your real state. Keep your durable private context in a gitignored file like state/insights.local.md. Keep daily notes gitignored too. Put secrets in local config files, Claude settings, or environment variables. The repo stays shareable. Your real operating system stays private.
What A Good First Version Actually Does
Don't aim for a magical AI life manager on day one. A good first version should do three things well:
- Tell you the highest-leverage next move.
- Find the conversations waiting on you.
- Show which meetings need prep before they hurt you.
Once that works, then you add errands, posting workflows, richer task automation, and deeper cross-tool reasoning.
Running vs Hosting
This starter runs through Claude Code on your machine, so it can keep working as long as your computer stays open and Claude Code is running.
If you want to host it as a real always-on agent, move it to the Claude Code SDK or another server-side setup. At that point you're no longer running on your Claude subscription. You're paying normal Anthropic API rates for the model and any tools you use.
Build It In Layers
If you haven't worked with Claude Code plugins, read the skills guide, the agents guide, and the MCP servers guide first. Those three concepts are the foundation of this workflow.