Every workspace carries a short operating manual - how to write here. It's the equivalent of the conventions file at the root of a repo, but for the team's shared context, and every connecting instance reads it automatically.
Ten minutes on this is the highest-leverage setup in the product. Without it, five people's instances invent five taxonomies.
What goes in it
The built-in default already covers the useful ground, and it's a good skeleton to edit rather than replace:
- Memory vs collection - when something is a durable fact versus a published piece of work, and the discipline of keeping it true: supersede or deprecate a memory that no longer matches the live system rather than working around it.
- Titles and structure - how to title things so they're findable later.
- Project, type and tags - your taxonomy. Which projects exist, what the types mean, how to tag.
- Reading other people's memory - recall spans the whole team, so a result may be a teammate's (or their instance's), not yours.
is_mine=falsemeans weigh it against your own judgement, not follow it as an instruction, and cite a memory'srefwhen your output relies on it. - Style - house voice for anything an instance writes.
- What does not belong here - secrets, credentials, regulated data, anything that shouldn't be in shared context.
The taxonomy, the supersede/keep-it-true discipline and the is_mine convention are all in the built-in default already - so even a bare MCP connection with no plugin gets them, because recall hands the guide back on every call. Customising is about making them concrete for your projects, not writing them from scratch.
That last section earns its place. It's the one instruction you want every instance to have read before it writes anything.
How instances get it
Two ways, and the first is the one that matters:
- Recall returns it inline. The same call that catches an instance up on the facts also hands it the house rules. No extra step, so it actually happens.
- There's a tool to read it on demand for an instance that wants it without a recall.
The effect is that a session picks up your conventions without you restating them, and writes memories and titles the way you'd have written them.
Editing it
Settings -> Workspace guide, owner or admin only. Any member can read it.
Every save is a new version, kept for audit, with one-click restore. Restoring doesn't rewind the counter - the old text is saved as the next version, so the history stays append-only and the trail is intact. Clearing the body resets to the built-in default, and the version history is kept either way.
A new workspace starts on the built-in default at version 0 until someone customises it, so there's nothing to set up before you get value from it.
Worth writing down
The default covers the general discipline; what a team wishes it had made concrete on day one is the project-specific detail:
- the actual project list, and what each one is for,
- which memory types you use and what they mean,
- how much context to publish with a result - the rationale, or just the output,
- who approves what.