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 page of a project or experiment. The agents that record your sessions keep it, and anything a person writes on it stays theirs. Edit it with probe summary checkout and probe summary push; see summaries. Runs have no Overview: an experiment’s summary is the write-up of its runs.

​
Notes

append adds a paragraph to the end, and keeps anything a teammate wrote meanwhile, so concurrent handoffs never overwrite one another. edit replaces one exact piece of text, which must appear exactly once. Both take literal text only. For anything larger, use checkout and push. (probe notes write replaces a project’s whole notes document without merging; keep it for a document you are authoring outright.)

​
The editing loop

Push merges. A paragraph a teammate wrote while you were editing survives; it is not silently overwritten. push --force replaces the server’s document without merging, deleting anything written since your checkout; it is an escape hatch, never a step in a routine. checkout --steal takes a checked-out file that has unpushed edits. Notes live on a project, an experiment or a run — --project, --experiment, --run — plus the one team note (--team, on append and edit). Files and run groups carry none: describe them in the notes of the run or experiment they belong to.

​
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.

​
Size limits

Notes are capped in tokens, not characters: Each sub-note has its own cap, the same as its entity’s. A write past the cap is refused with a message naming the limit. probe notes list shows each sub-note’s fullness as stored_tokens of limit_tokens, and a project, experiment or run read carries notes_tokens and notes_remaining_tokens.

​
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.