Conciseness

The body is dense and assumes competence — it never explains what WIP or cycle time is, and each step is a directive with a one-line rationale ('An improvement bet without a baseline is a story with a number in it'). It sits at 'efficient with minor instances that could be trimmed' rather than 5 because the aphoristic asides and some repetition across Workflow steps, Rules, and Quality Gates (baselines and the four families each appear in multiple sections) could be tightened slightly.

Actionability

Concrete, executable guidance dominates: 'Add ids to the `measure-set` island in `measures.md` and to each step's `measures:`. Run `flow_lint.py`' names exact files, fields, and a lint tool, and each step specifies verifiable outputs. It falls short of fully copy-paste-ready because `flow_lint.py` is never given an invocation path or command line, and the watermelon check (step 9) describes intent without a concrete procedure.

Workflow Clarity

The nine steps form a clear, well-ordered sequence (decisions → families → outcome → steering/watch split → wiring → sources → baselines → refusals → scheduled check) with an explicit validation checkpoint ('Run `flow_lint.py` — it fails on a step naming a measure nobody declared') and a Quality Gates checklist. It does not reach 5 because there is no explicit error-recovery loop (what to do when the lint fails) and the gates are stated as conditions without a fix-and-recheck cycle.

Progressive Disclosure

The body is a genuine overview (~65 lines) and the References section lists three files, each with a one-line description and one-level-deep signaling ('`skills/flow-driven/references/measurement.md` — the four families, the anti-measures...'). It misses 5 because the referenced paths are repo-relative rather than bundle-relative (`references/measurement.md`) and none of the referenced files exist in this skill's bundle, so navigation cannot be verified from the skill itself.

Specificity

The description lists multiple concrete capabilities with named measures per family — 'flow measures (WIP, age, cycle time, throughput, rework)', 'evidence measures (coverage, first-pass yield, escape rate, check agreement)', 'leverage measures (delegate mix, human minutes per item, escalation rate, cost per item)' — plus concrete wiring actions ('each measure named on the steps that feed it and a baseline taken before anything changes'). This matches the comprehensive-coverage anchor; it is not level 4 because there are no meaningful coverage gaps in what the skill does.

Completeness

It explicitly answers both questions: what it does ('Decide what a workflow should measure and wire it in' with the enumerated families and wiring/baseline behavior) and when to use it ('Use when defining a workflow, when a board has numbers nobody steers with, or before making any workflow-improvement bet'). This matches the anchor with concrete trigger phrases; a lower score would require a missing or only weakly implied 'when', which is not the case.

Trigger Term Quality

Triggers like 'Use when defining a workflow, when a board has numbers nobody steers with, or before making any workflow-improvement bet' give good natural phrasing, and terms like 'cycle time', 'throughput', 'baseline' are words users would say. It falls short of the comprehensive anchor because common synonyms such as 'metrics', 'KPIs', or 'dashboard' are absent and several terms (e.g., 'check agreement', 'escape rate') are internal jargon rather than user-spoken phrases.

Distinctiveness Conflict Risk

The measurement/instrumentation focus with triggers like 'a board has numbers nobody steers with' carves a mostly distinct niche with minor overlap risk. It does not reach 5 because 'Part of the flow-driven family' signals sibling skills in the same family that share the broad 'workflow' trigger space, and the description does not say what distinguishes this skill from those siblings.