Writing a charter

The charter is the personality. It decides what a staff member does when nobody is watching, what it refuses, and what it escalates.

roster will not write it for you. That is not a missing feature. A generated charter produces a generic agent, and a generic agent produces work that is competent-looking and about nothing in particular, which takes longer to notice than no work at all.

Write it with your own AI

Write the charter, on that staff member's card on the Staff screen, does the whole round trip. It copies a brief with every file it refers to already inside it, so a chat window with no filesystem is as useful as an agent standing in the repo. Paste the reply back into the box and you get a diff and a save button, never a silent write.

It runs about 19,000 characters, on purpose: one paste into a large-context model beats six rounds of it asking for files it will never get.

The peers' charters are in there, along with org/business.md and the shared operating layer. That is the part that matters most, because without them the model writes a second copy of whoever it was shown. The brief then interviews you, drafts from your answers, and tells you what it cut and why.

So is a worked example, when one fits. A staff member whose handle or role reads as one of the ten roles below gets the matching example inside the brief, labelled as a model for the shape and not content to copy. The copy-a-prompt panel has a picker to choose another or none; in a terminal it is --example <handle> or --example none. It is still a brief you answer: the interview comes first, and nothing in the charter should come from the example rather than from you.

From a terminal, the same brief:

roster brief charter <handle>            # or: roster brief charter cto | pbcopy

In Claude Code, cd <staff-dir> && claude then /charter runs the same text, because roster hire generates the slash command from it. There is nothing agent-specific in any of it.

What goes in it, and what does not

Only the difference. The shared half already exists in org/: how anyone here operates, how we write, the guardrails everyone is bound by. All of it is composed into the prompt above the charter. Restating any of it wastes context on every run of every day and creates two places to change one rule.

If a sentence would be true of every staff member you will ever hire, it belongs in org/.

The shape that has worked

Who I am. One paragraph. What this role is for, in this business specifically.

The mission. The single thing this staff member optimises. If a decision does not serve it, it is somebody else's decision.

How I work, that others here do not. The habits particular to this role.

Decision rights. What it decides alone, what it proposes and waits on, what it never touches. Be specific. A vague boundary is one that gets crossed at 07:00 with nobody awake.

Guardrails on top of the org's. Only the additions.

Where the rest of it lives. Point at memory/INDEX.md, log/decisions.md, the pinned status issue, and the surfaces the manifest declares.

Worked examples

Ten, for an invented company called Acme. The handle in brackets is the one --example takes.

They are examples to adapt, not templates to fill in. Read them for what a finished charter covers and how specific it gets, then write your own about your business. A charter copied from one of these describes Acme. The brief carries the matching one for you; these links are for reading them first.

Things worth being concrete about

• Escalation. Name the label and the mechanism, not the sentiment. "Open an issue labelled decision, assigned to @you" beats "check with the founder".
• What it must not do. Money, legal, anything touching a real person's data. Say it here even if org/guardrails.md covers it, if this role gets closer to the line than others.
• What good output looks like for this role. A CTO's and a CMO's differ, and the shared voice file cannot know that.

Keep it agreeing with the manifest

Health, and roster lint, fail if the charter and staff.yaml disagree. The manifest is the machine-readable half of the same document: handle, schedule, peers, surfaces, identities. If the charter says it reviews pull requests on the product repo, works_in had better include it.

It is not finished

The charter is the file most worth revisiting. When a run does something you did not want, the question is usually not "what went wrong in that run" but "what does the charter not say".