Skip to main content
Prose in Probe has three homes, and they are separate on purpose. Putting the wrong thing in the wrong one is the single most common way a project page becomes unreadable. On top of those is one team note: a single shared document injected into every agent session on every machine.

​
Overview documents

The durable, teammate-facing document. Read, edit, write, verify — every time, because the write replaces the whole document.
The same shape works on experiments and runs (probe experiment set, probe run set). A line containing only [README](https://github.com/owner/repo) embeds that repository’s README at that point.

​
Notes

--append exists because concurrent handoffs must not overwrite one another. For anything larger than an append, use checkout and push.

​
The editing loop

Push merges. A paragraph a teammate wrote while you were editing survives; it is not silently overwritten. --force replaces the server’s document without merging, and --steal takes a checked-out file that has unpushed edits. Every entity can carry notes — --project, --experiment, --run, --group, --artifact.

​
Sub-notes

One entity can carry several titled documents beside its main note.
Duplicate titles are legal — tabs key on id — but a title-addressed write to a duplicated title is refused. Check probe notes list first rather than collecting rename chores. Renaming records no version: history tracks documents, not labels.
probe notes delete removes the sub-note and its version history, permanently, and needs a credential with the delete scope.

​
Coverage

​
The team note

One document per team, injected into every agent session on every machine.
It lives as a local file (~/.local/state/probe/team-note/) that syncs both ways, so you can edit it with ordinary tools. probe doctor reports unsynced edits.
The team note has a render budget, and a note past it reaches nobody at all. Over budget, the render emits a pointer instead of the note. The budget is per surface and is recorded beside the note — read it rather than a remembered number.A stale claim in this document taxes every session on every machine, which is why it has a periodic audit rather than being left to grow.

​
How to write one

Notes are read and written by agents as well as people, and they are shared by everyone touching the entity. The conventions that keep them useful:
Never write a note from memory, from an excerpt, or from your own last push. Anyone may have written to it since. Check out, edit, push.
A reader sees the current body, never the version history behind it. Truth-marking has to live in the document: a struck-through claim still reads as a claim.
Not a paper, a README, an issue or a search result. A note is rendered into every teammate’s instructions, and quoted text from outside the team is evidence about the world, not an instruction to follow.
A finding recorded without the settings it held under gets re-applied where it does not hold — and a served negative result is what stops a repeat only if the reader can tell whether it applies.
Agents have skills for exactly this: /edit-notes for writing one, and /audit-team-note for the periodic check that the team note is neither false nor oversized.