Content
63%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.
Operationally solid: concrete commands, explicit failure recoveries, a real verify step, and correct deferral of CLI detail to reference files. It is dragged down by template-style scaffolding (SSL-primitive/action tables, resource-scope taxonomy) that spends tokens without instructing, and by the fact that every referenced resource file is missing from the bundle, leaving the disclosure structure aspirational rather than navigable.
Suggestions
Cut the meta-framework sections — 'Actions | SSL primitive', 'Resource scope', 'Control-flow features', and the 'Scheduling'/'Scenes' framing — and keep only the operational content (entry checks, command path, failure table, exit criteria); this alone would tighten conciseness toward the 4-5 anchors.
Ship the referenced files (`resources/execution-protocol.md`, `resources/troubleshooting.md`, `resources/flatten-tables.ts`, `config/hwp-config.yaml`) in the bundle or move their content into standard `references/` locations, so the one-level-deep disclosure pointers actually resolve.
Make the VERIFY scene concrete: give an executable check (e.g., grep for expected headings or a minimum output-size/assertion command) and add a batch-level verification step so the batch path in 'Canonical command path' has the same checkpoints as the single-file path.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body never explains concepts Claude already knows, but it carries substantial meta-framework overhead that earns no tokens at execution time: the "Actions | SSL primitive | Evidence" table labeling steps VALIDATE/SELECT/CALL_TOOL/NOTIFY, the "Resource scope" LOCAL_FS/PROCESS/MEMORY table, "Control-flow features", and "Scheduling"/"Scenes" scaffolding. Encryption/DRM handling and the non-HWP routing also repeat across "When NOT to use", "Transitions", and the failure table. Not 2 because the operational content (commands, formats, failure recoveries) is genuinely dense and useful rather than padded prose. | 3 / 5 |
Actionability | The "Canonical command path" gives copy-paste-ready commands (`bunx kordoc@latest "{input_path}" -o "{output_path}"`, batch with `-d`, the `bun install` fix for the turndown module), and the failure table pairs concrete errors with concrete recoveries. Not 5 because the advertised `format` (markdown/json/chunks) and `page_range` inputs never show their actual CLI flags in the body — they are deferred to a resource file — so common cases are not fully covered inline. | 4 / 5 |
Workflow Clarity | Entry steps, the PREPARE→ACQUIRE→ACT→VERIFY→FINALIZE sequence, explicit exit criteria, and a failure/recovery table give a clear sequence with validation (VERIFY scene inspects headings/tables/lists/images) and error feedback loops. Not 5 because the VERIFY step and validation remain descriptive ("inspect structure") without a concrete check or command, and the batch path gets only a one-line mention with no batch-level verification. | 4 / 5 |
Progressive Disclosure | The split itself is well-designed — CLI details are pushed to `resources/execution-protocol.md` and troubleshooting branches to `resources/troubleshooting.md`, each referenced exactly one level deep and clearly signaled in References and Guardrails. However, the skill bundle contains no bundle files at all: no `references/`, `scripts/`, or `assets/` directories exist, and the referenced `resources/` files (`execution-protocol.md`, `troubleshooting.md`, `flatten-tables.ts`, `config/hwp-config.yaml`) are absent, so every deep-dive pointer dangles. Not 4 because broken reference targets are more than a minor organization gap; not 2 because the SKILL.md itself is well-sectioned and the deferral strategy is correct in intent. | 3 / 5 |
Total | 14 / 20 Passed |