Universal release workflow. Auto-detects version files and changelogs. Supports Node.js, Python, Rust, Claude Plugin, and generic projects. Use when user says "release", "发布", "new version", "bump version", "push", "推送".
90
Quality
79%
Does it follow best practices?
Impact
98%
1.08xAverage score across 6 eval scenarios
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/release-skills/SKILL.mdDiscovery
82%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 skill description with excellent trigger term coverage including multilingual support and a clear 'Use when' clause. The main weaknesses are the somewhat abstract capability description (could list specific actions like tagging, changelog generation) and the inclusion of 'push' as a trigger term which risks conflicts with general git operations.
Suggestions
Add specific concrete actions like 'updates version numbers, generates changelog entries, creates git tags, publishes packages' to improve specificity
Consider removing or qualifying 'push' as a trigger term to avoid conflicts with general git push operations - perhaps 'push release' or 'push new version' instead
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (release workflow) and mentions auto-detection of version files and changelogs, plus lists supported project types. However, it doesn't list specific concrete actions like 'update version numbers', 'generate changelog entries', 'create git tags', etc. | 2 / 3 |
Completeness | Clearly answers both what (universal release workflow with auto-detection for multiple project types) and when (explicit 'Use when user says...' clause with specific trigger phrases). The explicit trigger guidance is present and comprehensive. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms including 'release', 'new version', 'bump version', 'push', and even Chinese equivalents '发布' and '推送'. These are terms users would naturally say when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | The term 'push' is problematic as it could conflict with git push operations that aren't releases. The release-specific terms are distinctive, but 'push' and '推送' are generic enough to cause false positives with version control skills. | 2 / 3 |
Total | 10 / 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 well-crafted, highly actionable release workflow skill with excellent workflow clarity and concrete executable guidance. The multi-step process is clearly sequenced with validation checkpoints and user confirmation. However, the skill is quite long and could benefit from splitting reference material (translation tables, configuration examples) into separate files for better progressive disclosure.
Suggestions
Extract the section title translations table and language detection rules into a separate REFERENCE.md file to reduce main skill length
Move the .releaserc.yml configuration documentation to a CONFIG.md file with a brief summary in the main skill
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but includes some redundant information. The translation tables and multiple example outputs add bulk that could be condensed. However, most content is necessary for the complex multi-step workflow. | 2 / 3 |
Actionability | Provides fully executable bash commands, specific git operations, clear file paths, and concrete examples throughout. The workflow steps include copy-paste ready commands like `git tag --sort=-v:refname | head -1` and `gh pr view <number> --json author`. | 3 / 3 |
Workflow Clarity | Excellent multi-step workflow with 9 clearly numbered steps, explicit validation checkpoints (Step 8 user confirmation before release), dry-run mode for preview, and clear sequencing. Breaking change detection and version bump rules are well-defined with priority ordering. | 3 / 3 |
Progressive Disclosure | Content is well-structured with clear sections and tables, but everything is in a single monolithic file. The configuration section and translation tables could be split into separate reference files. No external file references are provided for advanced topics. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
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.