/probe — the switch
The one skill that changes state rather than behaviour.
full / read-only / off — the older spelling, kept because every other copy of the client on the machine reads those files. Both spellings are accepted wherever a state is typed.
Where the Probe daemon records, the same switch reads on (daemon), read only (daemon) and off, and gains one more position, which only you can type:
/probe move hands Probe back to the daemon.
This skill does not track anything. It only moves the switch — and only when you move it.
.probe.config, the gitignore-style list of paths Probe never records whatever the switch says. See Keep folders out of Probe.
/track-work — the whole arc
Everything recorded while the switch is on. It is re-entered through the session rather than run once, and it triggers unprompted during ML work even when you did not ask for tracking.
The arc it enforces:
1
Orient against what exists
Check the team’s prior work before proposing a direction. Duplicated work is the failure this step exists to prevent.
2
Create the project and experiment explicitly
First, before the scaffold. Not inferred from a directory name at the end.
3
Route what the work produces
Files to artifacts on the right anchor, numbers to metrics, decisions to notes. Each has one correct home.
4
Get inputs into the run snapshot
So the run can be rebuilt rather than merely described.
5
Read back what actually landed
A queued write is not a delivered one. The claim needs a read.
6
Close with the real lifecycle outcome
completed, failed or canceled — whichever actually happened. When the work answers the experiment’s question, the agent records the answer and its evidence as the experiment’s conclusion (probe experiment set EXP --conclusion "..."), and keeps the summary current with /write-summary.reference.md holds the capture-call and artifact command syntax, the publication sequence, and project admin.
ML work is work on a model: training it, evaluating it, the data it learns from, or the research behind it. That covers evals, sweeps, prompt engineering checked against the model’s outputs, datasets, literature reviews, design decisions and the analysis of results. Setup (installs, drivers, provisioning, and a training repo’s CI fixes and dependency bumps) gets no run, only a short note when something trips you up. Product code that only calls a model, its CI and deploys, and work on Probe’s own code are not recorded. A session that holds both records only the ML part, and anything you ask to record is recorded.
/instrument-code — wire the SDK in
Wires probe.init and probe.log into a script that trains, evaluates, sweeps or serves.
It fires when writing or changing any such script, when launching one on another machine, when a trainer already has its own integration (Miles, TRL, VERL, Ray), and when a run finished green but recorded nothing, less than expected, or onto the wrong run.
/visualize-progress — where the work stands
Renders the tracked state, the gaps, and the arc as one timeline with the next action named. Fires on broad questions about the work, on arriving in an unfamiliar project, before a run starts or after one ends, and when planning next steps.
Its one rule: every line is a claim that needs a read, never a memory of this session. Writes queue, so
probe outbox status must be clean — or the run closed with probe run end — before a stage or a count is stated as done./edit-notes — how to write a note
The mechanism for writing any entity’s notes, and the shared team note. Loaded before any note write.
Its rules, in short: pull before you write, because anyone may have written since; never paste external text verbatim, because a note is rendered into every teammate’s instructions; correct or delete rather than striking through, because a reader sees the current body and never the history behind it.
See Notes and documents.
/audit-team-note — the periodic check
Ensures the team note carries nothing false and has not grown past its render budget. Uses /edit-notes for the actual editing, and is meant to run in a subagent or asynchronously so the audit never sits inline with your work.
The trigger is size, not the calendar.
/write-summary — the project and experiment pages
Each project and experiment has a summary: its Overview page, the page people read to catch up. Whoever records the work keeps it — the agent itself, or the Probe daemon’s writer. Nothing on the server writes it. See Summaries.
The agent writes the first one when it creates the project or experiment, then updates it on a result, a decision or a change of direction:
probe write of a session to a project or experiment checks its summary out on its own and prints the path. Blocks a person wrote on the page come back as <!-- kept: ... --> and are left alone.
Five page skills sit beside it, read before a page is edited:
/overview-visuals — tables and charts
Picks an experiment’s tables and charts in its Metrics center, or a project’s tables. The agent names fields and runs; the server reads the numbers itself.
/track-work has the agent set an experiment’s tables and charts when the experiment closes.
/plan-research-review — plan before code
Before the agent writes code for ML research (reproducing a paper, building on a paper’s or a repo’s code, a new method or experiment), it maps the plan to the code that already exists and asks you about every gap, instead of guessing.
It runs when you ask for it, or when the managed rules block says to. That routing line is the wizard’s Settings → Research plan review, on by default.
Where skills come from
Skills ship inside theprobe-research plugin and follow the Agent Skills standard, so they load in any host that implements it. Updating the plugin updates the skills — there is nothing to sync by hand.
Where the Probe daemon records, the agent gets the daemon profile instead: /probe, /instrument-code, /plan-research-review and /visualize-progress, and no MCP server. The daemon does the recording and the reading. /probe inline hands the recording skills back to the agent for that session.
Capy gets its own bundle (probe-capy, track-work, instrument-code, plan-research-review, edit-notes, audit-team-note). See Capy.