Content
88%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-crafted instruction skill: concrete git/gh commands at every step, a complete output template, explicit verification points (ref confirmation, diff-based claim verification, the release version check), and a final checklist. The two minor costs are a checklist that duplicates the body's rules and an inline output template that could live in a reference file.
Suggestions
Trim the Checklist to items not already enforced inline (e.g., keep the version-check and verified-credits items); most of its lines currently restate rules the body already gives, which doubles the token cost for the same instruction.
Move the full output template, including the fixed install block and plugin section, into references/release-template.md and point to it from the Output format section, keeping only the adaptation guidance ('Follow the closest of the recent releases inspected in step 1') inline.
Drop justifying clauses such as 'This is a repository release convention, not an optional style preference' and 'unless the user asked for release preparation too' style hedges where the bare imperative already conveys the rule.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is efficient and teaches only what Claude could not know: the em-dash ban, the drop-list for internal-only commits, exact install-block wording, and the version-check script. It falls short of 5 because the 10-item Checklist restates nearly every rule already stated in the body, and a few justifying clauses ('This is a repository release convention, not an optional style preference') could be trimmed to bare imperatives. | 4 / 5 |
Actionability | Every step is backed by copy-paste-ready commands: 'git describe --tags --abbrev=0 HEAD^', 'git log <previous-tag>..HEAD --pretty='%s (%h)'', 'gh release list --limit 5', 'node scripts/check_version_sync.mjs --release'. The full markdown output template covers the common case end-to-end, including the exact install block and conditional sections. | 5 / 5 |
Workflow Clarity | The four numbered steps are clearly sequenced, with explicit validation checkpoints: 'Confirm both refs with git rev-parse --verify before drafting', 'Do not infer a breaking change... Verify it in the diff', and the release-integrity check with failure handling ('If the check fails because the requested version has not been bumped yet, report that clearly'). The closing checklist adds a final verification pass. | 5 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are all absent), and the single-file body is well-sectioned with clear headers, all content appropriately inline for a single-task skill. It stops short of 5 because the ~35-line output template (including the fixed install block and plugin section) is a borderline candidate for a references/ file, which would keep the overview leaner. | 4 / 5 |
Total | 18 / 20 Passed |