/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.
This skill does not track anything. It only moves the switch — and only when you move it.
/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.reference.md holds the capture-call and artifact command syntax, the publication sequence, and project admin.
What counts as trackable is broader than training: evals, sweeps, literature reviews, architecture decisions, dataset processing — and the work that supports them, like provisioning for a training job or a config change before a launch. If you are unsure whether something deserves recording, it does.
/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.
/read-rules and /set-rule — workflow memory
/read-rules
Reads the team’s stored conventions for the situation you are about to be in. Before an irreversible or shared-consequence step, and on arriving in an unfamiliar workspace — never after.
/set-rule
Records one. Fires when you say how something should be done, or correct the agent in a way that applies to anyone doing this tomorrow.Nothing is written until you confirm it.
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.