velocity.report: Skill for Claude Code

Skill: experiment-review

Read what the experiments established, decide what to run next for one goal, and leave the queue in a state /run-experiments can pick up overnight and a person can pick up at the annotation window in the morning. The method is the one the October 18 review used for the following-distance metric: the chain from a capture to the product's figure, each link's measured state, and the cheapest experiment or the one labelled window that moves the weakest link. It is the weekly queue review the experiment queue plan asks for, and it writes specs, backlog edits and a review; it approves nothing.

Usage

/experiment-review                                 # the current goal, the next 7 days
/experiment-review following distance --days 7     # name the goal and the horizon
/experiment-review --area l5id --area geom          # only these areas' lines

Run it weekly, after the Monday research briefing and before an overnight /run-experiments, or whenever a run's reports land and the queue has gone quiet.

1. Read the state, not the memory of it

Everything below is read at origin/main's head, and the commit goes in the review's provenance.

git fetch origin main && git log --oneline -40 origin/main
go run ./cmd/tools/experiments next          # the open queue and what each waits on
go run ./cmd/tools/experiments status        # approved experiments' units and time left
gh pr list --state open                      # or the GitHub tools; what is in flight

Then, in this order:

1. data/experiments/DEPENDENCIES.md: every answered experiment's report, every open one's dependencies and estimates, the longest open chain.
2. The Recommendations, Summary and Limitations of every report the answered specs name, newest first. A recommendation is a question with no identifier until a spec carries it; list each one and whether a spec already does.
3. The goal's plan and sprint plan: the ledger of gates, what each gate's current state and remaining evidence are, and the backlog sections the goal lives in.
4. The briefings under docs/lidar/operations/brief/ for their Open questions and Decisions, and docs/DECISIONS.md for what was decided and what it was deferred on.
5. The memory notes of earlier overnight runs, where the session has them: which held-out segments were read for which measure, and the traps met.
6. The labelling tooling's state: docs/lidar/operations/point-annotation-tool.md, label-sets.md, and the plans' status lines, so a labelling task is sized against the tools that exist today, not the ones planned.