Purpose

/verification:measure answers "did the claimed improvement actually happen, by how much?" — it MEASURES a delta (before → after) against a baseline captured before the change. It is the measurable-delta twin of /verification:confirm (which confirms intent/outcome) and is distinct from a review gate (which reviews design quality for ship-readiness on an absolute axis).

Core rule: never claim improvement without a baseline captured before the change. If no baseline exists, report honestly — "Baseline not captured. Current measurement: X. Cannot quantify improvement." — and never fabricate a delta.

Two-phase model

The measurement mechanism is SSOT here; the planning stage routes to it when a plan states a measurable goal, /verification:confirm redirects improvement claims to it.

Phase	Stage	Who invokes	What it does
`baseline`	planning time (plan states a measurable goal)	`/verification:measure <family> baseline`	Capture pre-change measurements → store under the topic's memory-tier `baselines/` + record baseline + target in the plan
`compare`	after the change (default phase)	`/verification:measure <family>`	Re-measure under the same conditions → compare to the stored baseline → verify the claim

Baseline storage: the topic's memory tier — <memory_dir>/<slug>/baselines/ (default .work/), resolved per the topic-docs binding (${CLAUDE_PLUGIN_ROOT}/reference/topic-docs.md). Baselines are machine-bound measurements and are never committed; the plan artifact is contract-tier at <contract_dir>/<slug>/PLAN.md (default docs/topics/) and no longer sits beside them. The plan records the baseline values + target; the comparison summary surfaces in the plan and the PR body.

Measurement tooling: use whatever harness the consuming project wires (BenchmarkDotNet, pytest-benchmark, a metrics collector); when none exists, run both phases manually per the context-file discipline — do not add a harness speculatively.