Content
85%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.
An exceptionally actionable and well-gated release workflow: every step carries executable commands, explicit validation checkpoints, and feedback loops, and it encodes substantial non-obvious operational knowledge. The weaknesses are structural — a monolithic single-file layout with no progressive disclosure despite being long enough to warrant reference files — plus some repetition and essayistic prose that could be tightened.
Suggestions
Split the CHANGELOG style guidance ('Length and tone', good/bad examples, entry ordering) and the verification subagent prompt template into a references/ file (e.g. references/changelog-style.md) and link to it from the workflow steps, keeping SKILL.md as the sequenced overview.
Deduplicate the library-API-breaking-changes point: it is explained fully in step 5, in 'Version Guidelines', and again in 'Library API Compatibility' — state it once and cross-reference.
Verify that 'evals/README.md' and '../../../AGENTS.md' resolve as real files in the installed skill bundle, or inline/adjust the paths, since neither exists in the current bundle structure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Nearly all content is project-specific knowledge Claude cannot infer (why '--ff-only' instead of the 'up' alias, why 'nightly' hosts the full matrix while 'ci.yaml' moves to cargo-affected, the 49-to-101-word changelog ratchet), with no padding about concepts Claude already knows. Minor trimmable instances: the library-API-breaking point is stated three times (step 5, Version Guidelines, Library API Compatibility), and passages like 'Sentences stretch to fit whatever you want to say; words don't' are essayistic. Not 3: no section is padded or unnecessary on the whole; not 5: some justificatory prose and repetition could be cut. | 4 / 5 |
Actionability | Fully executable throughout: copy-paste commands ('gh workflow run nightly.yaml --ref main', 'cargo release X.Y.Z -p worktrunk -x --no-publish --no-push --no-tag --no-verify --no-confirm && cargo check', 'git tag vX.Y.Z origin/main && git push origin vX.Y.Z'), an executable awk word-count check, a complete verbatim subagent prompt template, and concrete good/bad changelog entry examples. Not 4: guidance goes beyond commands to exact escalation and monitoring procedures ('avoid gh run watch — it can hang'). | 5 / 5 |
Workflow Clarity | Thirteen explicitly sequenced steps with validation gates and feedback loops at every risky point: the test gate ('Fix any failure before continuing' with a ci-reporter monitoring the run), the changelog verification subagent with a re-run loop ('The pass ends on a clean run, not on the first run's findings'), data-loss sign-off before tagging ('Do not tag a release with an unresolved deletion-surface candidate'), and unresolved doc findings blocking the tag. Not 4: validation is not merely present — error-recovery loops and blocking conditions are explicit, matching the anchor-5 example's structure. | 5 / 5 |
Progressive Disclosure | The body is a ~370-line monolith with zero reference files in the bundle (no references/, scripts/, or assets/ directories exist), and the changelog style guide, verification prompt template, and contributor-crediting procedures (~200 lines) are inlined where they belong in separate files; its only pointers ('evals/README.md beside this skill', '../../../AGENTS.md') lead outside the bundle. Not 2: section structure is well-organized with working internal anchors ('see Data-Loss Surface Review below'), far above 'minimal structure'; not 4: most bulk detail sits in SKILL.md itself rather than in one-level-deep references, which the rationale calls for. | 3 / 5 |
Total | 17 / 20 Passed |