CtrlK
BlogDocsLog inGet started
Tessl Logo

openseo-release-notes

Cut an OpenSEO release — bump the version, draft user-facing release notes from commits since the last tag, run a review + subagent-verification pass, and open a "release: vX.X.X" PR. Use when the user asks to prepare a release, bump the version, or write release notes.

75

Quality

94%

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

96%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 excellent instructional skill body: lean, repo-specific, fully executable, and sequenced with genuine adversarial verification loops. The sole dimension below ceiling is progressive disclosure — the skill is monolithic at ~63 lines, though it appropriately delegates style to an exemplar file and needs no other external references.

DimensionReasoningScore

Conciseness

The body is dense, imperative, and carries only repo-specific judgment (canonical exemplar v0.0.24 vs. old-verbose v0.0.23, dual-repo PR lookup, credit rules, cut lists) that Claude cannot know. It never explains concepts Claude already knows, and every rule is load-bearing for the curation task. Anchor 4 ('minor over-explanation that could be trimmed') fits less well — lines like the cut-priority and credit rules are all actionable policy, not padding.

5 / 5

Actionability

Fully executable guidance throughout: exact commands (`git tag --sort=-creatordate | head -1`, `gh pr view <num> --json title,body,author`, the complete `gh release create` invocation), exact file paths, branch naming (`claude/v<version>`), PR title format, concrete bullet exemplars ("Redesigned the app layout"), and the exact changelog URL template. Anchor 4's 'minor gaps' does not apply — copy-paste-ready commands cover the common cases.

5 / 5

Workflow Clarity

Five clearly numbered sections in correct dependency order with explicit validation checkpoints: branch-up-to-date check with flagging, PR-body-vs-commit-subject disagreement resolution, a reviewer subagent pass, adversarial verification subagents returning APPLY/APPLY-MODIFIED/REJECT, and 'Apply only verified comments'. This matches the anchor-5 pattern (sequence + explicit validation + feedback loops), exceeding anchor 4 which allows minor validation gaps.

5 / 5

Progressive Disclosure

Well-organized single-file skill with clear section navigation, and it correctly points to a one-level-deep external exemplar (`docs/release-notes/v0.0.24.md`) rather than inlining its style. However, the body is ~63 lines — above the under-50-line simple-skill exception that would let well-organized sections alone score 5 — and the detailed curation rules (the 'Do NOT mention' list) could conceivably live in a reference file. Anchor 5 fits slightly less well than anchor 4.

4 / 5

Total

19

/

20

Passed

Description

92%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: it names the full workflow concretely in third person, includes an explicit 'Use when...' trigger clause with natural phrases, and occupies a distinct niche. The only weakness is trigger synonym coverage — a few natural phrasings ('cut a release', 'changelog') are absent.

DimensionReasoningScore

Specificity

Quotes four concrete actions — "bump the version", "draft user-facing release notes from commits since the last tag", "run a review + subagent-verification pass", "open a 'release: vX.X.X' PR" — comprehensive coverage of the release workflow with no vague filler. Anchor 4 ('minor gaps in coverage') fits less well since every action in the workflow is named specifically; no action is left abstract.

5 / 5

Completeness

Explicitly answers both: 'what' (bump version, draft notes from commits since last tag, review/verify, open PR) and 'when' ("Use when the user asks to prepare a release, bump the version, or write release notes") with concrete trigger phrases. Matches the anchor-5 example pattern exactly; not the 4 anchor since 'when' is fully explicit, not just present.

5 / 5

Trigger Term Quality

The trigger clause "Use when the user asks to prepare a release, bump the version, or write release notes" covers natural phrases well. Anchor 5 requires comprehensive synonym coverage (e.g., 'cut a release', 'changelog', 'publish'); a few natural variations are missing, so it sits between anchors 4 and 5, squarely at 4.

4 / 5

Distinctiveness Conflict Risk

A clear niche — cutting an OpenSEO release with repo-specific versioning and PR conventions — with distinct triggers (release, version bump, release notes) unlikely to fire for other skills. Overlap risk with generic changelog/commit skills is minimal given the explicit OpenSEO and release-PR scoping.

5 / 5

Total

19

/

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

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

Total

14

/

16

Passed

Repository
every-app/open-seo
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.