Docs / Instruction tips
ModelBrain gives your assistant tools. Your project instructions decide whether it reaches for them. A few plain sentences, pasted once, turn "it sometimes remembers" into "it checks memory first and saves what matters."
Paste this into your assistant's standing instructions, then trim it to taste:
When I ask about my own projects, people, decisions or preferences, call recall first and answer from what it returns. If recall finds nothing, say so instead of guessing. When I state a decision, a preference, a deadline or a durable fact, call remember. Do not save small talk or things that will be stale tomorrow. Label what you save: set object_type (for example decision, preference, fact, task) and add a few short tags. If a new fact replaces an older one, pass supersedes with the old memory's id so the old one stops surfacing. Keep work for different efforts in separate partitions. Use partition_use at the start of a session for the effort we are on. Housekeeping: if ModelBrain does not respond, tell me plainly and carry on without it.
Every line maps to a real tool: recall, remember, partition_use. The tips below explain why each line is worth having and how to sharpen it.
CLAUDE.md. Client setup already installs a skill and a prompt hook for you, so add only what is specific to your work.Assistants only call a tool when something tells them to. Name the situations: questions about your projects, people, past decisions, or anything starting with "what did we" or "remind me". A trigger beats a general "use memory when helpful."
Without a rule, assistants save too much or nothing. List the kinds of facts you want kept (decisions and their reasons, preferences, deadlines, who owns what) and the kinds you do not (chit-chat, one-off questions, anything that changes by tomorrow).
remember accepts an object_type and tags. Pick a small fixed vocabulary and tell the assistant to use it. Tags are matched exactly and are case-sensitive, so Launch and launch are different tags. Consistency is the whole benefit.
When something changes, tell the assistant to pass supersedes with the old memory's id. The old fact stops surfacing and the history stays inspectable. remember also returns similar existing memories, so ask the assistant to look at that list before it adds a near-duplicate.
Create one partition per client, product or area with partition_create, and switch with partition_use. The binding is per connection, and a fresh connection starts in the default partition, so put the switch in your instructions rather than assuming it carried over. Recall can widen to all partitions when you want that.
For questions about you rather than your documents, tell the assistant to use recall with scope user, or list_memories when there is no query at all. That keeps your notes folder out of the way of a simple preference lookup.
remember has an inferred flag. If you want a clean line between what you said and what the assistant concluded, instruct it to set inferred on anything it deduced rather than heard.
recall can run a deeper reasoning pass for questions that need two or more facts stitched together. It costs more time, so reserve it for those. Every recall response carries a reasoning_status, and a good instruction is "if it says reasoning did not run, say so before answering."
A folder connector reads what you point it at. Point it at the notes, not at a directory that also holds build output or scratch files. Common log and temp directories are skipped, but plain-text logs elsewhere are still read. See what folders read and skip.
forget reverts by default, and has chain and object modes for wider removal. Tell the assistant to ask which you mean before it uses the wider ones. Add a line telling it to report plainly if ModelBrain is unreachable, so you find out the same day.
Vague lines such as "remember everything important" or "use memory a lot" produce uneven behavior. Prefer a trigger, a category and a tool name. If a line cannot be checked by reading one conversation, rewrite it until it can.