Content
77%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A well-engineered protocol skill: the 7-step workflow is clearly sequenced with per-step checkpoints, explicit error-recovery loops, and clean one-level-deep progressive disclosure into five real reference files. The weaknesses are mild repetition of the same rules across the checkpoints, Output Shape, and Stops sections, and a handful of directives that lean on jargon defined only in the reference files.
Suggestions
State each governing rule once and cross-reference it: 'unknown is not pass' (Step 3 checkpoint vs Output field 2) and the unverified-completion rule (intro outcome 2, Step 7, Stop 2) each appear 2-3 times — pick one canonical location and point to it to trim the body's token cost.
Cut or compress sections that restate reference-file content in the body, e.g. the lightweight-path paragraph's path-selection rationale and the 'Not a cost gate' bullet, which duplicate material that delegation-contract.md and scoped-criteria.md already own.
Add a one-line gloss (or an early pointer to the defining reference) for protocol terms used before their reference is first read — 'saturate from v0' (Step 6) and 'C-class criterion' (Step 3) currently force the reader to open a reference file to parse the step.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly efficient — it does not explain concepts Claude already knows, and nearly every line adds a protocol rule — but several rules are stated two or three times across step checkpoints, the Output Shape, and the Stops section (e.g., 'unknown is not pass' appears in both Step 3 and Output field 2; the unverified-completion rule appears in the intro, Step 7, and Stop 2), and passages like the lightweight-path paragraph could be tightened. This matches anchor 3 ('mostly efficient but includes some unnecessary explanation or could be tightened') better than anchor 4, where only minor trimming would be needed. | 3 / 5 |
Actionability | As an instruction-only skill, it provides concrete, executable guidance: fixed inventory order, a defined verdict vocabulary ('pass / fail (name the failure mode) / unknown'), an explicit probe termination clause ('max two attempts across methods per candidate'), per-step checkpoints, and a fully specified output shape with named fields. It falls short of anchor 5 because a few directives depend on terms not defined in the body before their reference is read ('saturate from v0', 'C-class criterion') and 'check current authorization' lacks a concrete mechanism — but the guidance is far beyond the incomplete/pseudocode level of anchor 3. | 4 / 5 |
Workflow Clarity | The sequence (Steps 0-7, with a defined lightweight path) is explicit, every step carries a validation checkpoint, and error-recovery feedback loops are specified: 0-survivor diagnosis ('axis wrong vs candidate set incomplete' with 'the stalled probe and recovery condition'), probe termination after two failures, early-exit outcomes, and the two Stops. This matches anchor 5 — clear sequence, explicit validation steps, feedback loops for error recovery, and a checklist structure — and the destructive/batch cap does not apply since verification is built in. | 5 / 5 |
Progressive Disclosure | SKILL.md is a genuine overview/protocol and all detailed material lives in five reference files, each present on disk and signaled with both an in-step 'Read [file](references/...)' instruction at the point of need and a 'Read when' table. References are one level deep (sibling cross-links between reference files, no nested chains), matching anchor 5 — clear overview, well-signaled one-level-deep references, easy navigation. | 5 / 5 |
Total | 17 / 20 Passed |