Content
96%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 dense, honest, and executable body: every section documents non-inferable package behavior with runnable code, and the batch audit workflow includes explicit validation and error-recovery loops. The only structural gap is that some reference-grade detail (exception table, claim-key minutiae) is inlined in SKILL.md rather than split into a bundled reference file.
Suggestions
Split reference-grade detail — the exception taxonomy table, constructor options, and the strict claim-key specification — into a one-level-deep file under references/ linked from the relevant sections, keeping SKILL.md an overview.
Reduce the duplication between the 'Two input kinds' paragraph and its Pitfalls recap (and the twice-repeated pointer to the sibling api/cli skills) once that reference file exists, trimming the body toward a leaner main file.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line carries package-specific behavior Claude could not infer — "`format()` returns **whole-batch** `.text`/`.html` covering every input, newline-joined — not one string per item", "**`entry.input_index` is the 0-based position in the list you passed in**", "`audit_bibliography()` sends chunks **serially even in the async client**" — with zero tutorial padding about Python, DOIs, or citation styles. Not 4: the only repetition (the Pitfalls recap of the `kind=` rules) is deliberate quick-reference design and earns its place. | 5 / 5 |
Actionability | Fully executable, copy-paste-ready snippets cover every common case: `verify()` with a real DOI, `audit_bibliography()` with a progress callback and `needs_review` iteration, `export()` writing a file, exception handling keyed on `.code` and `.retry_after`, async context-manager usage, and a runnable Verification section. Not 4: no common case lacks ready-to-run code, and inputs/outputs of each snippet are concrete. | 5 / 5 |
Workflow Clarity | The batch workflow has explicit validation checkpoints: pre-flight input strictness ("Claim dicts are strict — the server rejects unknown keys … Strip anything else before sending", "Two input kinds, and the wrong one fails"), error recovery that preserves completed work ("A failed chunk is recorded, not raised" with a `report.errors` loop and `stop_on_error` option), and a dedicated Verification section with a health check and a deliberate-mismatch test. The batch-operation cap of 3 does not apply since validation is present. Not 4: checkpoints are explicit rather than implicit, and verdict semantics are tabulated so each outcome has a defined next step. | 5 / 5 |
Progressive Disclosure | The single file is well sectioned (When to Use / Install / API surface / Procedure / Errors / Authentication / Pitfalls / Verification) with a method table and nothing buried, but at roughly 240 lines with no bundle files, reference-grade detail such as the full exception taxonomy and the audit claim-key specification could live in a one-level-deep referenced file. Not 5: the under-50-lines no-references exception does not apply and no content is split across files; not 3: nothing is monolithic — sections are clearly signaled and easy to navigate. | 4 / 5 |
Total | 19 / 20 Passed |