CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

release

Create a release from dev branch. Generates changelog entries from commits, bumps version, and creates a PR to main. TRIGGERS - Use this skill when user says: - "/release" - create a patch release (default) - "/release minor" - create a minor release - "/release major" - create a major release - "make a release", "cut a release", "ship it", "release to main"

68

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

77%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.

An exceptionally actionable, well-validated release workflow where nearly every token encodes repo-specific gotchas that Claude could not reconstruct. The weaknesses are structural: everything lives in one ~800-line file with no progressive disclosure, and the closing Important Rules section duplicates inline guidance enough to cost meaningful tokens.

Suggestions

Split the body into reference files and keep SKILL.md a lean overview: move the 'Recovery: deterministic release CI failure' section and the Homebrew formula template + verification script into references/ (e.g. references/recovery.md, references/homebrew.md), leaving one-level-deep, clearly signaled pointers.

Deduplicate the 'Important Rules' section against the inline guidance — each rule (atomic version+sha256, --no-rebase, main..dev boundary, tap sync, pre-flight smoke) is currently stated both at its step and again at the bottom; state each once to cut token cost without losing the guardrails.

Trim explanations of git mechanics Claude already knows (e.g. why fast-forward is impossible across a squash merge, what pull.rebase=true would do) to one-line notes, preserving only the repo-specific consequences of each rule.

DimensionReasoningScore

Conciseness

Mostly efficient — the bulk is repo-specific operational knowledge Claude cannot know (squash-merge changelog boundary, CI update-homebrew race, checksum verification) that earns its tokens — but the "Important Rules" section restates rules already explained inline (the atomic version+sha256 rule, --no-rebase, and the main..dev boundary each appear two to three times), and some git mechanics Claude already knows (why fast-forward is impossible across a squash merge, what pull.rebase does) are over-explained. Not 2 because there is no generic-concept padding and the code comments carry non-obvious, load-bearing rationale.

3 / 5

Actionability

Fully executable, copy-paste-ready guidance: complete bash blocks including the awk per-platform digest cross-check that follows each url line, the full regenerable Homebrew formula template, drift/convergence checks via git merge-base, and concrete gh commands. Placeholders like vx.y.z and <N> are clearly parameters rather than pseudocode.

5 / 5

Workflow Clarity

Twelve explicitly sequenced steps with fail-closed validation checkpoints at every risky boundary (dev-contains-main drift check, pre-flight compiled-binary smoke, changelog boundary sanity-check against the previous release's PR numbers, formula verification against published checksums, post-sync convergence check, /test-release end-to-end verification), plus a dedicated recovery section with rerun/diagnose/fix feedback loops. This is a batch/destructive-adjacent workflow and validation is abundant, so no cap applies.

5 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are all absent) and the body is a single ~800-line monolith. Internal structure is good (numbered steps, headed sections, clearly separated recovery section), which keeps it above anchor 2, but content that clearly belongs in separate files is inlined: the deterministic-CI-failure recovery procedure, the full Homebrew formula template, and the changelog writing rules would each work as one-level-deep reference files, leaving SKILL.md a lean overview.

3 / 5

Total

16

/

20

Passed

Description

91%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.

A strong description with an explicit what/when structure, concrete third-person actions, and a well-chosen set of natural trigger phrases. The only weaknesses are the omission of the post-merge scope (tagging, Homebrew formula, tap sync, verification) from the what-clause and one mildly generic trigger ("ship it").

DimensionReasoningScore

Specificity

The description lists four concrete actions ("Create a release from dev branch. Generates changelog entries from commits, bumps version, and creates a PR to main") but omits significant parts of the skill's actual scope (tagging, GitHub Release, Homebrew formula update, tap sync), so it is 'several specific actions with minor gaps in coverage' rather than comprehensive. Voice is third-person throughout.

4 / 5

Completeness

Explicitly answers both questions: what ("Create a release from dev branch. Generates changelog entries from commits, bumps version, and creates a PR to main") and when ("Use this skill when user says: /release... make a release, cut a release, ship it, release to main") with concrete trigger phrases, matching the top anchor.

5 / 5

Trigger Term Quality

Trigger terms cover natural synonyms and command forms users would actually say: "make a release", "cut a release", "ship it", "release to main", plus the /release, /release minor, and /release major slash-command variants. Not below 5 because no common natural phrasing for requesting a release is obviously missing.

5 / 5

Distinctiveness Conflict Risk

Mostly distinct: "cut a release", "release to main", and the /release commands are unambiguously release-specific, but "ship it" is a generic phrase that could also match a deploy/ship skill, which is exactly 'minor overlap risk with closely related skills'. Not 3, since the trigger list is dominated by unambiguous release terms rather than being merely 'somewhat specific'.

4 / 5

Total

18

/

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

skill_md_line_count

SKILL.md is long (824 lines); consider splitting into references/ and linking

Warning

referenced_paths_exist

Referenced path issues: 4 missing

Warning

Total

14

/

16

Passed

Repository

coleam00/Archon

Path

.claude/skills/release/SKILL.md

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.