Build your own chief of staff

01What separates this from a chat window

• It persists. You stop re-explaining who you are, what you do, and how you want to be written to.
• It routes. One file, CLAUDE.md, tells the assistant where to look before it answers. Ask about a project and it reads that project's file first.
• It compounds. Every workflow you write down makes the next run faster. The system is sharper in month six than in week one.
• It chases. This is the part people skip, and it is the part that earns the name. A real chief of staff tells you the thing you are waiting on has been sitting with someone else for eighteen days. Yours can too, if you build it that way.

02Before you start

1. Install Claude Code from claude.com/claude-code, or use the Claude desktop app, which has it built in.
2. Have a Claude account. The paid Pro plan works. Max is worth it if this becomes central to your work.
3. Pick the home folder and do not move it. Something like ~/chief-of-staff/. Putting it inside a synced drive means it follows you between machines, which is usually the right call.
4. Set aside forty-five uninterrupted minutes. The setup is an interview. Rushed answers produce a generic assistant.

Decide one thing before you begin: what is in scope. Work only, or work and personal? There is no wrong answer, but the assistant will hold whatever you give it, so decide on purpose.

03Day one is an interview

Open Claude Code in your new, empty folder and paste the prompt below as your first message. It interviews you, then builds the system from your answers.

Answer honestly rather than aspirationally. "I dread starting slide decks from nothing" is worth more than "I would like to be more efficient."

You are about to become my personal Chief of Staff: a persistent AI assistant that lives in
this folder and works with me over months and years.

Before you build anything, interview me. Ask one section at a time. Wait for my answer.
Ask follow-up questions when an answer is thin. Do not generate any files until the
interview is finished and I have confirmed.

INTERVIEW

1. IDENTITY
   - Name, what I go by, titles
   - What I actually do, in plain language
   - The three to five things that fill most of my week
   - Roles I hold inside my organization
   - Roles I hold outside it

2. TOOLS
   - AI tools I use today and what I use each one for
   - Systems I work in daily: email, calendar, documents, and whatever is specific to my field
   - Anything I cannot connect to, because it is locked down or has no API

3. PAIN POINTS
   - What I dread starting from a blank page
   - What I repeat often enough that it should be a template
   - Where things fall through the cracks
   - Push me here. Ask for a concrete example of each. The generic answer is not useful.

4. VOICE
   - How I want you to talk to me
   - What you must never do
   - What you must always do
   - Are you a thinking partner who pushes back, or an order-taker? Ask me to commit.

5. PROACTIVITY, meaning how I want to be chased
   - Should you raise things I have not asked about? When?
   - How do I want to hear that something is slipping: bluntly, gently, or with options?
   - What is my daily rhythm, and when would a nudge actually land?

6. GUARDRAILS
   - What may you never do without my explicit approval, each time? Sending email and
     posting publicly are the usual two.
   - What categories of information must never appear in anything shareable?
   - What should you always ask me about rather than decide yourself?

7. ONGOING WORK
   - Projects that span more than one sitting
   - People I work with repeatedly, and what each relationship is
   - Recurring deadlines and the rhythm of my year

8. RECURRING WORKFLOWS
   - Things I do regularly that follow a pattern
   - For each: what goes in, what I actually do, what comes out, and what makes it good

BUILD

When the interview is done, show me a summary and ask me to confirm. Then build:

  CLAUDE.md
  daily/
  threads/
    _portfolio.md
  skills/
  references/
  registry/
    tools.md
    skills-index.md
    people.md
  deliverables/
    _oneoffs/
  assets/

CLAUDE.md, under 200 lines, containing:
  - Identity: who I am
  - About me: roles, responsibilities, tools
  - How to show up: voice, never-rules, always-rules, thinking-partner stance
  - Proactivity: when and how to raise things I did not ask about
  - Guardrails: what needs my approval every time, what never goes in a shareable artifact
  - Routing rules: skills first, then threads, then references, then registries, then the daily log
  - Memory protocol: daily logs in daily/YYYY-MM-DD.md, threads for anything spanning sessions
  - Skill protocol: codify anything done twice; the stub format
  - Deliverables rule: outputs go in deliverables/<thread-name>/, archive the prior version
    before writing a new one
  - Hygiene: monthly review, keep this file under 200 lines
  - Cheat sheet: how I will typically use you each day

For each workflow I described, write skills/<name>.md with: when to use, inputs needed,
process, output format, quality checks, notes.

For each ongoing project, write threads/<name>.md with: what it is, status, key people,
open questions, next action.

Create threads/_portfolio.md as a markdown table with one row per thread and these columns:
thread, cluster, state, ball (who owes the next move), moved (date of last real movement),
chase (the date I chase if the ball is not mine), due, next action, flags. Fill in what you
know from the interview and leave the rest blank. Note in the file that a blank chase date
on a ball that is not mine is a defect, not an empty cell.

Populate the registry files. Create today's daily log. Then show me the tree, tell me what
you would do first, and ask me for one real task to run right now.

Start the interview.

04Four kinds of file, four questions

Almost every "where does this go" question has the same answer once you see the difference.

chief-of-staff/
  CLAUDE.md        the router, read at every session start
  daily/           YYYY-MM-DD.md, what happened
  threads/         one file per live project
    _portfolio.md  the state of every thread, in one table
  skills/          one file per repeatable process
  references/      stable knowledge, style guides, frameworks
  registry/        tools, people, an index of your own skills
  deliverables/    outputs, filed under the thread they belong to
  assets/          raw material: logos, templates, exports

Three rules that took me a while to learn

• A skill is a process, not a topic. "Grading" is a topic. "Grade a forum post against the rubric, compared with the rest of the class" is a skill.
• Open the thread on the second deliverable, not the first. One memo is a one-off. Two memos on the same subject means there is a project, and it needs somewhere to keep its state.
• Archive before you overwrite. Move the current version into archive/, then write the new one with today's date. You will want the old version eventually, always at the worst moment.

CLAUDE.md is a router, not a knowledge base. When it starts to grow too long, the fix is never a bigger CLAUDE.md. It is a new reference file with one line pointing at it.

05The part that makes it staff

Everything above gives you a very good filing cabinet. This is the part that makes it a chief of staff.

Work does not usually die from being hard. It dies from being quietly parked in somebody else's court while you assume it is moving.

You sent the email. They did not reply. Nothing broke, nobody complained, and three weeks later the thing is cold and you have lost the thread, and some credibility with it. The fix is one file and one script.

The file

threads/_portfolio.md. One row per project. Four columns do the real work: ball (who owes the next move), moved (the date something actually happened, not the date you thought about it), chase (the date you go get it, if the ball is not yours), and next (the next physical action, in a sentence).

Example rows. Row three is the whole point: nobody is doing anything wrong, and it is dying anyway.

The script

Have your assistant write a small script that reads the file and shows a board, coloring rows by how long they have been sitting. This matters more than it sounds.

If you ask the model to judge status in prose each morning, you get a slightly different judgment every day and you cannot check any of them. If a script applies fixed rules to a file you control, the judgment lives in your file, the arithmetic lives in the code, and the board never invents a status. Print the rules on the board so you can check them.

Then let it run without you

Claude Code can run tasks on a schedule. Three that pay for themselves:

• A weekday morning brief. Refreshes the board, names what has gone stale, tells you which chase dates land today.
• Batched email triage, a few times a day. It reads, sorts, and drafts. It does not send. The point is not speed. The point is that email stops rewriting your day at 9:14 in the morning.
• A weekly review. One honest pass across everything, where you decide again what actually matters this week.

Build these in month two, not week one. You need real projects in the file before a board is worth looking at.

06Three habits, seconds each

The system does not run on discipline. It runs on three small habits.

• Capture in the moment. Say "log this" after a call, a decision, a realization. Two sentences. Future you works with whatever present you bothered to write down.
• Write it down on the second repeat. The first time is a one-off. The second time is a pattern. Say "we have done this twice, make it a skill." Do not build skills in advance for work you imagine doing.
• Answer the chase question. When your assistant says a project has been sitting for two weeks, do not just acknowledge it. Move it, set a chase date, or end it. The projects you refuse to decide on are the ones that die.

Add a fourth once a month: fifteen minutes of cleanup. Archive what finished, remove what died, fix what drifted.

07What to add, and when

Resist building all of this on day one. Add each layer only once the layer beneath it is in real use.

08Guardrails, set on day one

Set these before you are in a hurry and tempted to skip them.

• Draft, never send. No email, no message, no public post goes out without you reading it and saying yes, each time. Not a blanket approval. This one rule prevents the mistake you would most regret.
• Keep private things out of anything shareable. Some things must never appear in anything you share: sensitive personnel matters, health, family, finances, anything told to you in confidence. Name those categories in CLAUDE.md. Where something gets published, exclude them in the code rather than trusting a written reminder.
• Ask before anything irreversible. Deleting, overwriting, or anything that costs money or reaches an audience.
• Memory is a budget, not a warehouse. Anything loaded every session competes with the work in front of you. Out-of-date memory is worse than none, because it is confidently wrong.

09How this fails

The honest failure modes, in the order people hit them.

• Building everything before using any of it. Forty skill files for workflows you have never run. Everything built in advance is a guess. Everything built on the second repeat is evidence.
• Letting the router become the knowledge base. Past 200 lines, CLAUDE.md stops being read carefully and starts being skimmed, by you and by the model.
• Skipping the voice section. Generic Claude is perfectly good. It only feels like your chief of staff if you told it how to talk to you, including what never to do. Be specific. "Do not open with a compliment" is a real instruction.
• Treating it as an order-taker. The value is in the argument. If it never tells you your plan has a hole in it, you have set up a very expensive autocomplete.
• Automating before the manual version works. A scheduled routine that produces something you do not read is worse than nothing. It is noise you have trained yourself to ignore.
• Never deciding what ends. Projects pile up. Some deserve to be closed, not chased. If everything is live, nothing is.

10What good looks like at ninety days

Not a bigger folder. Four things:

• You have stopped starting from a blank page for anything you do more than twice.
• You know at any moment what is waiting on someone else, and for how long, without going to look.
• It tells you things you did not ask about, and it is right often enough that you listen.
• Something that would have quietly died did not, because it got chased.

If you have those four, the folder structure was never the point. It was the frame that keeps your own work in view.