release
Generic release assistant — analyzes repo release rules, caches them in .omc/RELEASE_RULE.md, then guides the release
50
55%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/release/SKILL.mdQuality
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description conveys the general domain (release management) and mentions a distinctive caching mechanism, but lacks explicit trigger guidance ('Use when...'), concrete action details, and natural user-facing keywords. It reads more like an internal summary than a skill selector description.
Suggestions
Add an explicit 'Use when...' clause with trigger terms like 'release', 'publish', 'version bump', 'tag', 'deploy', 'cut a release', or 'changelog'.
Replace the vague 'guides the release' with specific actions such as 'creates tags, updates changelogs, bumps version numbers, and runs release scripts'.
Include common file/tool references users might mention, such as 'CHANGELOG.md', 'package.json version', 'git tag', or 'semantic versioning'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (release management) and some actions (analyzes repo release rules, caches them, guides the release), but the actions are somewhat vague — 'guides the release' is not concrete, and it doesn't specify what kinds of releases or what guidance entails. | 2 / 3 |
Completeness | Describes what it does (analyzes release rules, caches them, guides release) but has no explicit 'Use when...' clause or trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also somewhat weak, so this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes 'release' and 'repo' as relevant keywords, but misses common variations users might say like 'deploy', 'publish', 'version bump', 'tag', 'changelog', or 'ship'. The term 'release rules' is somewhat niche. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of '.omc/RELEASE_RULE.md' caching adds some distinctiveness, and 'release' is a reasonably specific domain. However, 'generic release assistant' is broad and could overlap with CI/CD, deployment, or versioning skills. | 2 / 3 |
Total | 7 / 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-structured, highly actionable release skill with a clear multi-step workflow and good validation checkpoints. Its main weaknesses are moderate verbosity (explaining concepts Claude already knows, like what git tags are or why build artifacts shouldn't be committed) and a monolithic structure that would benefit from splitting detailed templates and scaffolding guidance into separate files.
Suggestions
Trim explanatory content Claude already knows — e.g., remove the paragraph explaining why build artifacts inflate repo size, what git tags let tools understand, and the 'what makes a good release note' section. Replace with terse directives.
Extract the `.omc/RELEASE_RULE.md` template, the release notes guidance, and the first-time setup scaffolding offers into separate bundle files referenced from the main SKILL.md to improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long (~200 lines) and includes some explanatory content that Claude doesn't need (e.g., explaining what good release notes are, explaining what git tags do, explaining why build artifacts shouldn't be committed). However, much of the content is structural and necessary for a complex multi-step workflow. Could be tightened by ~30%. | 2 / 3 |
Actionability | The skill provides concrete, executable commands throughout (git tag, git push, gh run list, npm publish, twine upload), specific file paths to inspect, exact commit message formats, and clear template structures. The analysis checklist in Step 1 is highly specific about what to look for and where. | 3 / 3 |
Workflow Clarity | The 8-step workflow is clearly sequenced with explicit validation checkpoints: Step 4 is a pre-release checklist requiring confirmation, Step 2 runs tests before committing, Step 8 verifies CI status and registry publication. There's a clear feedback loop with the delta check in Step 0 and the first-time setup gap detection feeding into Step 7's remediation offers. | 3 / 3 |
Progressive Disclosure | The content is entirely monolithic — everything lives in a single SKILL.md with no bundle files or references to external documents. The release rules template, example changelog formats, and first-time setup scaffolding suggestions could all be split into separate referenced files. For a skill this long and complex, the lack of any content splitting is a missed opportunity. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- Yeachan-Heo/oh-my-claudecode
- Commit
3e94567
- Reviewed
Table of Contents
Is this your skill?
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.