Content
80%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 highly actionable, token-efficient body with excellent progressive disclosure and real operational detail (pagination caps, output formats, per-host behavior). The main defect is an inconsistent mode-numbering scheme between the Workflow and Command Pattern sections, plus some duplicated guidance that could be consolidated.
Suggestions
Reconcile the mode numbering: the Workflow section numbers local-progress/list/retrieve/resume as Modes 1-4, while the Command Pattern comments and 'Always Do This' label list/retrieve/download as Modes 1-3 — adopt one scheme so 'run Mode 2 before Mode 3' is unambiguous.
Deduplicate repeated guidance: the download-status-first preference and the never-rerun-start rule each appear two to three times across Workflow, Always Do This, and Outputs — state each once in Always Do This and reference it.
Consider moving the host-runtime specifics (Codex heartbeat automation, write_stdin polling, foreground/yield rules) into a short reference file so SKILL.md stays a lean overview for all runtimes.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Overall efficient — no explanations of concepts Claude already knows, and dense with non-obvious operational detail (streamed JSONL output, auto-pagination, idempotency_key capture). Not a 5 because guidance is repeated across sections ("prefer `download-status` before remote calls" appears in Workflow, Always Do This, and Outputs; "never run `start` again" appears at lines 19 and 73) and several host-specific sentences (Codex heartbeat/yield handling) run long enough to be distracting. | 4 / 5 |
Actionability | Fully executable copy-paste-ready commands for every operation: all six resource `list` calls with `--limit`/`--format`/`head` caps, all six `retrieve` calls, and `download-status`/`download-results` invocations with concrete flags and a note to substitute placeholders with absolute paths. Not a 4 because the common cases (list, retrieve, resume) are each covered with complete, runnable commands plus expected output semantics. | 5 / 5 |
Workflow Clarity | The sequence and decision rules are present (prefer `download-status` locally, retrieve before download to capture `idempotency_key`, probe resources until one succeeds, never re-run `start`), but the mode numbering is inconsistent: the Workflow section defines four modes (1=local progress, 2=list, 3=retrieve, 4=resume) while the Command Pattern and Always Do This sections use a different numbering (Mode 1=list, Mode 2=retrieve, Mode 3=download), leaving "Mode 1" and "Mode 2" ambiguous. Not a 4 because this labeling conflict is a real navigation gap, not a minor one; not a 2 because the underlying steps and checkpoints are otherwise clearly sequenced and the skill is read-only, so the destructive/batch validation cap does not apply. | 3 / 5 |
Progressive Disclosure | The body is a well-organized overview with clearly signaled, one-level-deep references: "Read [references/resume.md] before recovering a dropped session..." and "Read [references/api.md] for per-resource `list` columns, `retrieve` fields..." — both files exist, contain the promised material, and reference only each other (no nested chains). Not a 4 because navigation is explicit about when each file is needed and the split (overview vs. per-resource detail vs. resume semantics) matches the anchor example exactly. | 5 / 5 |
Total | 17 / 20 Passed |