> ## Documentation Index > Fetch the complete documentation index at: https://docs.prbe.ai/llms.txt > Use this file to discover all available pages before exploring further. # Notes and documents > The three homes for prose, the checkout/push editing loop, sub-notes, and the shared team note. 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. | | Where it shows | Who writes it | Write semantics | | - | - | - | - | | **`description`** | Everywhere the entity is listed | Anyone | Short field | | **Overview** (the [summary](/tracking/summaries.md)) | A project's or experiment's page | The recorders, plus blocks people keep | Checkout, edit, push; merges | | **notes** | The notes surface; read by agents | Agents and people | Append, merge-on-push, sub-notes | 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](/tracking/summaries.md). Runs have no Overview: an experiment's summary is the write-up of its runs. ## Notes ```bash theme={null} probe notes show --project folding probe notes append --project folding --text "Handoff: the lr sweep is done; seed 3 diverged and is excluded." probe notes edit --project folding --old "seed 3 diverged" --new "seeds 3 and 5 diverged" ``` `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 ```bash theme={null} probe notes checkout --run $RUN # pull the note to a local file $EDITOR probe notes push --run $RUN # send it back, merging ``` **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. ```bash theme={null} probe notes list --project folding # titles, fullness, when. No bodies probe notes create --project folding --title "eval protocol" probe notes show --project folding --note "eval protocol" probe notes checkout --project folding --note "eval protocol" probe notes rename --project folding --note "eval protocol" --to "evaluation protocol" probe notes delete --project folding --note "old protocol" ``` 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. > [!WARNING] > > `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: | Notes of | Cap | | - | - | | A project, an experiment, or the team note | 30,000 tokens | | A run | 2,000 tokens | 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`. ```bash theme={null} probe notes status # how full every notes document in this team is ``` ## The team note One document per team, injected into every agent session on every machine. ```bash theme={null} probe notes team # print it probe notes sync # reconcile the local file with the server probe notes audit-advisory # the audit line, or nothing — for hooks, not humans ``` 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. > [!WARNING] > > **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: > **Pull before you write** > > 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. > **Correct or delete — never strike through** > > 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. > **Never paste external text verbatim** > > 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. > **Carry the conditions, not just the conclusion** > > 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`](/agents/skills) for writing one, and `/audit-team-note` for the periodic check that the team note is neither false nor oversized. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.