Worktrunk release workflow. Use when user asks to "do a release", "release a new version", "cut a release", or wants to publish a new version to crates.io and GitHub.
85
83%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description with excellent trigger terms and a clear 'Use when' clause that makes it easy for Claude to select. The main weakness is that the 'what' portion could be more specific about the concrete steps involved in the release workflow (e.g., version bumping, changelog updates, tagging). Overall it performs well for skill selection purposes.
Suggestions
Add specific concrete actions to the description, e.g., 'Bumps version numbers, updates changelog, creates git tags, and publishes crates to crates.io and creates GitHub releases.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain ('release workflow') and implies actions like publishing to crates.io and GitHub, but doesn't list the specific concrete steps involved (e.g., bump version, update changelog, create git tag, publish crate). | 2 / 3 |
Completeness | Clearly answers both 'what' (Worktrunk release workflow, publish to crates.io and GitHub) and 'when' (explicit 'Use when' clause with multiple trigger phrases). | 3 / 3 |
Trigger Term Quality | Includes excellent natural trigger phrases: 'do a release', 'release a new version', 'cut a release', 'publish a new version', 'crates.io', and 'GitHub' — these are terms users would naturally say when requesting this workflow. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — scoped to 'Worktrunk' specifically, mentions crates.io (Rust ecosystem) and GitHub publishing, making it very unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, highly actionable release workflow skill with excellent step sequencing, concrete commands, and robust validation checkpoints including a mandatory subagent verification step. Its main weakness is length — the changelog-related sections (contributor credits, issue reporter credits, verification) comprise over half the document and could benefit from being extracted into a referenced file. The content is project-specific and valuable, but the token cost is high for what could be more concisely structured.
Suggestions
Extract the CHANGELOG Review section (including contributor credits, issue reporter credits, and mandatory verification) into a separate CHANGELOG_GUIDE.md and reference it from the main workflow with a one-line summary.
Tighten the 'Credit Issue Reporters' section — the 'When to credit' and 'Skip credit for' lists could be condensed into a single concise guideline.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~200 lines) with substantial detail on changelog verification, contributor crediting, and issue reporter crediting. While much of this is project-specific knowledge Claude wouldn't have, the subagent prompt template and extensive explanation of when to credit reporters could be tightened. The 'Finding reporters — do ALL three steps' section is thorough but verbose. | 2 / 3 |
Actionability | Excellent actionability throughout — every step has concrete, copy-paste-ready commands (cargo release, git log, gh issue view, git tag). The troubleshooting section provides exact recovery commands. The subagent prompt template is fully specified and ready to use. | 3 / 3 |
Workflow Clarity | The 11-step workflow is clearly sequenced with explicit validation checkpoints: running tests first, mandatory changelog verification via subagent before finalizing, user confirmation before proceeding with version bump, and polling for CI completion. The reset-and-recommit pattern in steps 6-8 is well-explained with rationale. Error recovery is addressed in troubleshooting. | 3 / 3 |
Progressive Disclosure | The content is entirely inline in one file with no references to external documents. The changelog section (credit contributors, credit reporters, verify entries) is very detailed and could be split into a separate CHANGELOG_GUIDE.md. The skill reads as somewhat monolithic despite good use of headers and subsections. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 9 / 11 Passed | |
65e58d3
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.