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 provides a basic sense of the skill's purpose (release management) and mentions a distinctive caching mechanism, but it lacks concrete action details and has no explicit trigger guidance. The phrase 'guides the release' is vague, and the absence of a 'Use when...' clause significantly weakens its utility for skill selection among many options.
Suggestions
Add an explicit 'Use when...' clause with natural trigger terms like 'cut a release', 'version bump', 'changelog', 'tag a version', 'publish', or 'ship'.
Replace 'guides the release' with specific concrete actions such as 'generates changelogs, bumps version numbers, creates git tags, and publishes releases'.
Clarify what 'analyzes repo release rules' means in practice — e.g., 'reads RELEASE_RULE.md or repo conventions to determine versioning scheme and release workflow'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (repo releases) and some actions (analyzes 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 release actions it performs (e.g., tagging, changelog generation, version bumping). | 2 / 3 |
Completeness | Describes what it does at a high level but has no explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is entirely missing, which per the rubric should cap this at 2, but the 'what' is also weak/vague ('guides the release'), so this falls to 1. | 1 / 3 |
Trigger Term Quality | Includes 'release' and 'repo' as relevant keywords, but misses common variations users might say like 'version bump', 'changelog', 'tag', 'deploy', 'publish', 'cut a release', 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 enough that it 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-designed, highly actionable release skill with excellent workflow clarity and concrete commands throughout. Its main weakness is length — the monolithic structure packs ~200 lines into a single file, and some sections (release notes guidance, first-time setup suggestions) explain concepts Claude already understands. Splitting auxiliary content into referenced files and trimming explanatory prose would significantly improve token efficiency.
Suggestions
Extract the release notes guidance (Step 5) and first-time setup suggestions (Step 7) into separate referenced files (e.g., RELEASE_NOTES_GUIDE.md, FIRST_TIME_SETUP.md) to reduce the main skill's token footprint.
Remove explanatory content Claude already knows, such as why build artifacts shouldn't be committed, what annotated tags are, and general descriptions of what good release notes look like — instead, just specify the format and rules to follow.
| 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 annotated tags are, what good release notes look like, 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 repo analysis checklist in Step 1 gives precise instructions on what to look for and where. | 3 / 3 |
Workflow Clarity | The 8-step workflow is clearly sequenced with logical dependencies (analyze → cache rules → determine version → checklist → release notes → execute → verify). It includes explicit validation checkpoints: pre-release checklist confirmation (Step 4), test gate execution before commit (Step 6.2), and post-push verification (Step 8) with error recovery flagging. The delta-check mechanism in Step 0 is a thoughtful feedback loop. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and numbered steps, but it's entirely monolithic — everything lives in one file with no references to supporting documents. The first-time setup suggestions (Step 7), release notes guidance (Step 5), and the detailed repo analysis criteria (Step 1) could be split into separate reference files to keep the main skill leaner. | 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
679b418
- 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.