CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

release-change-analyzer

Compares HEAD with the latest published version to analyze real changes, group by type, and recommend version bumps. Use before publishing a release to understand what actually changed.

66

Quality

83%

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

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

The skill is a well-structured, actionable guide for analyzing unpublished changes, with concrete commands and a clear output template. Its main gaps are minor: some redundancy between Step 2 and the Anti-Patterns, placeholder values in commands, and implicit rather than explicit validation for edge cases like a missing published version.

Suggestions

Consolidate the Anti-Patterns section with Step 2's 'MUST read the actual diff' guidance to remove duplicated emphasis and save tokens.

Add an explicit checkpoint for the case where no published version or tag exists (e.g., what to do when `git tag` returns nothing or npm reports 'not published'), which would also strengthen workflow validation.

Show one concrete end-to-end invocation with real values (e.g., `git diff v1.2.3..HEAD --stat`) instead of only `v{published-version}` placeholders.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence (no concept explanations), but the Anti-Patterns section partially restates Step 2's 'MUST read the actual diff' emphasis and the closing attribution line adds tokens without operational value.

4 / 5

Actionability

Provides concrete executable commands (npm view, pip index versions, git tag, git diff) plus a full output template and a version-bump decision table, but the `v{published-version}` placeholders require substitution and there is no worked end-to-end example with real values.

4 / 5

Workflow Clarity

A clear three-step sequence (identify published version, analyze diff, group and report) with a fallback in Step 1 (`|| echo "not published"`), but validation for edge cases such as missing tags or an empty diff is implicit rather than an explicit checkpoint. The workflow is read-only analysis, so the destructive/batch validation cap does not apply.

4 / 5

Progressive Disclosure

A simple, single-purpose skill with no bundle files; every section (When to Use, three Steps, decision table, Anti-Patterns, Example) is appropriately inline and well-signaled, so nothing warrants splitting into separate files.

5 / 5

Total

17

/

20

Passed

Description

80%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 names its niche and concrete actions in third person with an explicit when-clause. It falls just short of top marks on trigger coverage: adding natural synonyms users would say (release notes, changelog, since last release) would strengthen both completeness and distinctiveness.

Suggestions

Add natural trigger synonyms such as 'release notes', 'changelog', or 'what changed since the last release' to broaden keyword coverage.

Extend the when-clause to cover more trigger scenarios, e.g., 'Use before publishing a release, when deciding a version bump, or when writing release notes based on real code changes.'

DimensionReasoningScore

Specificity

The description lists multiple concrete actions in third person — 'Compares HEAD with the latest published version to analyze real changes, group by type, and recommend version bumps' — covering the full workflow (compare, analyze, group, recommend) with no gaps within its niche.

5 / 5

Completeness

Both what and when are explicit ('Use before publishing a release to understand what actually changed'), but the when-clause covers a single scenario rather than multiple concrete trigger phrases as in the anchor-5 example.

4 / 5

Trigger Term Quality

Good natural keywords ('publishing a release', 'version bumps', 'HEAD', 'published version') but common variations users would say are missing, such as 'release notes', 'changelog', 'since last release', or 'semver'.

4 / 5

Distinctiveness Conflict Risk

A clear release/versioning niche with distinct triggers ('HEAD', 'published version', 'version bumps') makes it mostly distinct, with only minor overlap risk against closely related changelog or commit-message skills.

4 / 5

Total

17

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

ArabelaTso/Skills-4-SE

Path

skills/release-change-analyzer/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.