After this guide, your chief of staff can draft a two-page constitution for your system, with an identity paragraph, a read-every-session list, a vault map, core operating rules, audit rails, and a decision-authority table you approve line by line.

The Drift Problem

A capable assistant with no standing rules re-decides its own role every session. This is not a capability failure — it shows up most clearly in the strongest models, because they are the most willing to be helpful in whichever direction the conversation leans. Monday it files everything meticulously; Tuesday it over-explains and under-files; Wednesday it sends something it should have drafted. What drift costs is not any single mistake. It is trust, which erodes faster than it rebuilds.

The fix is a document the system reads before it acts, every time. Claude Code injects a file called CLAUDE.md from the working folder into every session automatically. Most people use it for build commands. For a chief of staff, it is something much bigger: the employment contract.

What the Constitution Is — and What It Is Not

Mechanically, it is a Markdown file at the root of the vault. Because it is the one file with a guaranteed read, the biggest design decision is what not to put in it:

  • State does not belong there. Facts about your ventures, people, and projects live in the vault. If the constitution changes weekly, state is leaking into it.
  • Prompts about tone do not belong there. Rules about role and authority do.
  • Detail does not belong there. Push it down into the files the constitution points at. A model follows a two-page constitution far more reliably than a twenty-page one.

What It Should Contain

1. Identity and Mission, in One Paragraph

Open with who the assistant is and what it is not:

“You are my chief of staff. Your job is to ingest my data inputs, maintain state across my ventures, and brief me on what matters. You are not a generic assistant — you operate by the rules in this document.”

The “not a generic assistant” line matters. Without it, helpful-assistant defaults leak into everything: it over-explains, over-asks, and under-files.

2. A Read-These-Every-Session List

A short list of files the assistant must load before acting: who you are and your escalation triggers; the decision log; the operating cadence; the anti-patterns list; and — above all — the feedback log of past corrections. This is the mechanism by which last month’s lessons shape today’s judgment. See The feedback log.

3. The Vault Map

A directory tree of the whole system with one-line annotations, so the assistant always knows where a fact belongs. See The vault.

4. Core Operating Rules

Ten or so numbered rules. The load-bearing ones:

  • Truth lives in files. When you state a new fact, it is written to the right file before the reply.
  • Manager, not operator. The chief of staff holds no external credentials; named team members do.
  • Sub-agents read; the parent acts. Curators research and summarise. Only the chief of staff edits files, creates tasks, or sends anything.
  • Never collapse the review layers. Triage, briefing, and acting are separate operations.
  • Every brief item must demand a response. No FYI fluff in the daily brief.
  • Family time is a venture. Same calendar, same brief, same priority weight.
  • No fabrication. Not in the files, not from a curator: “I don’t know.”

5. Edit Authority with Audit Rails

The assistant may edit any knowledge file autonomously. Safety comes from rails, not gates: one git commit per edit with a structured message; a provenance comment in the file itself; a line in the day’s curation log; a brief that surfaces the diff; and a correction loop that turns “you got X wrong” into a feedback-log entry. See Files are memory.

6. A Decision-Authority Table

The single most trust-building section. Spell out exactly what the assistant may do alone and what it may never do. This gets its own guide: The decision-authority table.

7. Conventions

Task-labelling rules, the concrete-action title rule, naming patterns, and the rule that structural decisions get a decision record written before the assistant acts on them.

8. A “When in Doubt” Clause

Ours ends: re-read the identity file, the decision log, and the feedback log; check the relevant venture folder; then ask rather than guess. A clarifying question costs thirty seconds; a wrong action costs trust.

What Keeps It Healthy

  • Keep it stable. It should change rarely, and every change should be a decision record.
  • Keep it short enough to be obeyed. If a rule needs three paragraphs of nuance, the nuance goes in a linked file and the rule stays one line.
  • Let the feedback log amend it. When the same lesson appears three times in the feedback log, it gets promoted to a standing lesson — effectively a constitutional amendment without touching the constitution.
  • Re-read it quarterly, with your own eyes. Is the chief of staff working on the right things? Edit the identity paragraph to match what you now need.

A Minimal First Version

You do not need all eight sections on day one. Identity, the read-every-session list, three or four operating rules, the decision-authority table, and the when-in-doubt clause is a complete constitution for a system with no curators and no channel yet. Add sections when the first felt limitation arrives.

See it

The demo vault has a real constitution, with its seventeen authority rows approved line by line. It is fictional, and it was built by Claude Code sessions running the bootstrap prompt — not written by hand.

#constitution · #claude-md · #operating-rules

Hand this to your chief of staff. Plain Markdown: /guides/the-constitution.md. Tell it: "Read this guide and tell me what in our system it would change."

Also for your Claude: whole-site index · bootstrap prompt · guide feed