CtrlK
BlogDocsLog inGet started
Tessl Logo

release

Use this skill for EVERY ClawRouter release. Enforces the full checklist — version sync, CHANGELOG, build, tests, npm publish, git tag, GitHub release. No step can be skipped.

68

Quality

85%

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

SKILL.md
Quality
Evals
Security

Quality

Content

81%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 highly actionable, well-sequenced release runbook with strong validation checkpoints and error-recovery guidance. Its main weakness is the verbose Step 4, which buries a simple "no action required" conclusion under legacy-server backstory and code that belongs in a reference file.

Suggestions

Compress Step 4 to its actionable core ("No file edit needed — the server auto-fetches the version from the npm registry after publish") and move the pre-v0.12.x history, the TypeScript snippet, and the implications into a short references/deprecated-sync.md linked from that step.

Fold the three 'Implications' bullets in Step 4 into the existing Common Mistakes table (which already covers the hand-editing mistake), eliminating duplicated guidance and saving ~20 lines.

Tighten the CHANGELOG section by replacing the 'Rules' bullet list with the two normative bullets (date format, one bullet per logical change) since 'no see git log' and 'include all changes' restate the template above them.

DimensionReasoningScore

Conciseness

Most steps are lean one-line commands, but Step 4 spends roughly 40 lines on blockrun server backstory — pre-v0.12.x history, an inline TypeScript snippet of the server's fetch code, and three "Implications" bullets — where a sentence ("No action needed; the server auto-fetches the version from the npm registry") would suffice. This exceeds the 'minor instances of over-explanation' of anchor 4, though the rest of the body is efficient.

3 / 5

Actionability

Every step provides copy-paste-ready commands: version check via grep, concrete git/npm/gh invocations including the sed-based release-notes extraction, expected npm publish output, and a five-point final verification block. Placeholders ({VERSION}, {DATE}) are clearly signaled.

5 / 5

Workflow Clarity

Twelve clearly ordered steps with explicit gating ("All must pass. Fix failures before proceeding"), a dedicated final verification step checking five artifacts with mismatch handling ("If any mismatch, fix before declaring the release done"), and a Common Mistakes table mapping each failure mode to its prevention step — a full feedback loop for a hard-to-reverse publish operation.

5 / 5

Progressive Disclosure

The skill is a single self-contained file (no references/, scripts/, or assets/ exist) with well-organized numbered sections and a mistakes table, appropriate for a linear checklist. The gap keeping it below 5 is that Step 4's server-internals explanation would sit better in a short reference file, keeping the main body purely procedural.

4 / 5

Total

17

/

20

Passed

Description

83%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 that clearly states what the skill does and when to use it, with concrete action coverage and a well-chosen set of trigger phrases. The only improvement would be folding a "Use when..." clause with concrete trigger phrasing into the description itself rather than relying on the separate triggers list.

DimensionReasoningScore

Specificity

The description enumerates seven concrete release actions ("version sync, CHANGELOG, build, tests, npm publish, git tag, GitHub release"), giving comprehensive coverage of the release pipeline with no vague filler.

5 / 5

Completeness

Both what ("Enforces the full checklist — version sync, CHANGELOG, build, tests, npm publish, git tag, GitHub release") and when ("Use this skill for EVERY ClawRouter release") are explicit, matching anchor 4. Not 5 because the concrete trigger phrases live in the separate triggers list rather than the description itself; not 3 because the when clause is explicit, not weakly implied.

4 / 5

Trigger Term Quality

The triggers list covers natural phrases users would say ("release clawrouter", "ship clawrouter", "publish clawrouter", "version bump clawrouter", "npm publish clawrouter") with good synonym coverage, but misses common variations like "cut a release" or "roll out". This sits between anchor 3 (missing common variations) and anchor 5 (comprehensive), closer to 4.

4 / 5

Distinctiveness Conflict Risk

The description names a specific product (ClawRouter) and a specific release workflow with distinct trigger phrases, creating a clear niche with minimal overlap risk against generic versioning or publishing skills.

5 / 5

Total

18

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

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

Warning

Total

15

/

16

Passed

Repository
BlockRunAI/ClawRouter
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.