CtrlK
BlogDocsLog inGet started
Tessl Logo

release

Generic release assistant — analyzes repo release rules, caches them in .omc/RELEASE_RULE.md, then guides the release

61

Quality

73%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/release/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

88%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A strong, highly actionable workflow skill: every step carries concrete commands, a derivation template, or a checklist, and the flow is validated end-to-end. The only real weaknesses are the absence of any 'when to use' trigger guidance in the frontmatter and a small block of generic release-notes advice that Claude largely already knows.

DimensionReasoningScore

Conciseness

The body is dominated by lean, imperative, executable instructions with no padding about concepts Claude doesn't know, fitting the 'efficient; minor instances of over-explanation' anchor. It is not level 5 because Step 5's 'What makes a good release note' block re-explains knowledge Claude already has; not level 3 because such instances are minor relative to the overall structure.

4 / 5

Actionability

Fully executable throughout: exact commands (`git tag -a vX.Y.Z -m "vX.Y.Z"`, `gh run list --workflow=<release workflow> --limit=3`, `git log <prev-tag>..HEAD --no-merges --format="%s"`), a concrete `.omc/RELEASE_RULE.md` file template, a pre-release checklist, and an example changelog entry. This matches the 'fully executable; copy-paste ready' anchor.

5 / 5

Workflow Clarity

Steps 0-8 are clearly sequenced with explicit validation checkpoints: the Step 4 checklist requires user confirmation before proceeding, the test gate runs before tagging, and Step 8 verifies CI status, registry publication, and the GitHub release with instructions to report failures. This matches the 'clear sequence with explicit validation steps; feedback loops; checklists' anchor.

5 / 5

Progressive Disclosure

The skill is a single well-sectioned file with no bundle files, and headers/numbered steps make navigation easy, fitting the 'good structure; most content appropriately placed' anchor. It is not level 5 because the Step 5 release-notes guidance and Step 7 first-time-setup message templates are self-contained blocks that could be split into reference files if the skill grows.

4 / 5

Total

18

/

20

Passed

Description

58%Weight 40%Scale 1-5

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 communicates a clear, concrete capability set with a specific cache artifact, but lacks any 'when to use' trigger guidance and underuses the natural vocabulary of releases. Adding a 'Use when...' clause with synonyms like publish, version bump, tag, and changelog would raise both completeness and trigger term quality.

Suggestions

Add an explicit 'Use when...' clause (e.g., 'Use when the user asks to release, publish, bump the version, or cut a tag') to satisfy the completeness requirement.

Include natural trigger synonyms users actually say — 'publish', 'version bump', 'ship', 'tag', 'changelog' — to improve trigger term coverage.

Drop the word 'Generic' and name 1-2 more concrete actions (e.g., 'bumps version files, tags, and verifies the publish') to sharpen specificity and distinctiveness.

DimensionReasoningScore

Specificity

The description lists several concrete actions — "analyzes repo release rules", "caches them in .omc/RELEASE_RULE.md", "then guides the release" — matching the 'several specific actions; minor gaps' anchor. It is not level 5 because 'guides the release' is generic and there is no mention of version bumping, tagging, or publishing; not level 3 because more than 1-2 actions are named and the cache location is concrete.

4 / 5

Completeness

The 'what' is clear (analyze repo release rules, cache them, guide the release), but there is no 'Use when...' clause or equivalent trigger guidance, which the rubric explicitly caps at 3. It is above level 2 because the 'what' is concrete rather than vague.

3 / 5

Trigger Term Quality

"release", "repo", and "guides the release" are relevant keywords, but the description misses common natural variations users would say such as 'publish', 'version bump', 'ship', 'tag', or 'changelog'. This matches the 'some relevant keywords but missing common variations or synonyms' anchor and falls short of level 4's 'good keyword coverage'.

3 / 5

Distinctiveness Conflict Risk

The release workflow is a distinct niche with only minor overlap risk against related versioning or changelog skills. The leading word "Generic" slightly weakens distinctiveness, keeping it below level 5's 'clear niche with distinct triggers'.

4 / 5

Total

14

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

14

/

16

Passed

Repository
Yeachan-Heo/oh-my-claudecode
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.