CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

release-plannotator

Prepare and execute a Plannotator release — draft release notes with full contributor credit, bump versions across all package files, build in dependency order, and kick off the tag-driven release pipeline. Use this skill whenever the user mentions preparing a release, bumping versions, writing release notes, tagging a release, or publishing. Also trigger when the user says things like "let's ship", "prep a release", "what's changed since last release", or "time to cut a new version".

Quality

89%

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

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.

The body is an exceptionally actionable, well-sequenced release runbook with explicit validation gates, error-recovery loops, and real, well-annotated reference examples. Its main weaknesses are token efficiency (redundant restatements, checklist narration, and deep pipeline background inline) and a monolithic 315-line structure where the security/verification detail could be split into a reference file.

Suggestions

Move the Phase 4 pipeline internals (SBOM/Grype policy detail, VEX exception policy, tag-only verification commands) into a reference file such as references/release-verification.md, keeping a short summary and the monitoring checklist inline.

Remove the second restatement of the 10-file version rule in Phase 2 — the table plus the check-release-version command already establish it once.

Tighten the checklist to bare assertions with their commands, moving the incident justifications (the 0.28.32 Pi Node floor and 0.28.33 install.sh stories) into a short notes section or the relevant phase.

DimensionReasoningScore

Conciseness

Most content is necessary and project-specific (exact file tables, command sequences, workflow names), but there is real tightening opportunity: the 10-file version rule is stated twice ("Bump the version string in these 10 files" table, then re-explained including "apps/dsh-plugin/package.json... are among them"), the checklist re-narrates body content with long incident justifications (0.28.32, 0.28.33 anecdotes), and Phase 4's ~40 lines of pipeline internals (Grype database policy, VEX exception policy, SBOM scope) explain what CI does rather than what the agent does. This fits the 3 anchor (mostly efficient but could be tightened); 4 would require only minor instances of over-explanation, and 2 would require padded concept-teaching, which is absent.

3 / 5

Actionability

Guidance is fully executable throughout: exact commands for every phase ("git tag --sort=-v:refname | head -1", "gh pr view <number> --json title,author,body,closedIssues,labels", the build sequence, "gh run watch <run-id> --exit-status", the full attestation-verify and sha256sum blocks), an exact 10-file version table, and copy-paste workflow-dispatch loops. Matches the 5 anchor (copy-paste ready commands covering common cases).

5 / 5

Workflow Clarity

Four phases are clearly sequenced, with explicit validation checkpoints ("Read each file, confirm the current version matches expectations", "Do not tag until all five runs succeeded on the bump commit", "Verify all builds succeed before proceeding"), feedback loops for error recovery ("If one fails, fix it on main and run them again", "If anything is missing, fix it before proceeding to Phase 4", the viewer-pin-live recovery procedure), and before/after-tagging checklists. This is a direct match for the 5 anchor.

5 / 5

Progressive Disclosure

References are one level deep, clearly signaled, and real (all three cited files — release-notes-v0.12.0.md, v0.13.0.md, v0.13.1.md — exist in references/), each annotated with when to use which pattern. However, a meaningful slice of inline content (the Phase 4 pipeline/SBOM/attestation internals and tag-only verification procedure, roughly 80 lines) is self-contained and would fit better in a reference file, so the SKILL.md leans long at ~315 lines. Fits the 4 anchor (good structure, references clear, minor-to-moderate organization gaps); 3 would require references to be unclear or un-signaled, which they are not.

4 / 5

Total

17

/

20

Passed

Description

96%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 states what the skill does in concrete, third-person terms and gives explicit, natural trigger guidance including colloquial release phrasings. The only weakness is that several trigger terms are generic release vocabulary that could collide with release-management skills for other projects.

DimensionReasoningScore

Specificity

The description lists four concrete actions covering the full workflow — "draft release notes with full contributor credit", "bump versions across all package files", "build in dependency order", and "kick off the tag-driven release pipeline" — with comprehensive coverage and no gaps. This matches the 5 anchor (multiple specific concrete actions, comprehensive); 4 would require minor gaps in coverage, which are absent.

5 / 5

Completeness

Both questions are answered explicitly: the "what" is the four concrete actions, and the "when" is given twice — "Use this skill whenever the user mentions..." and "Also trigger when the user says things like 'let's ship'..." — with concrete trigger phrases. This is a direct match for the 5 anchor; 4 would require the 'when' to be less explicit, which it is not.

5 / 5

Trigger Term Quality

Formal triggers ("preparing a release", "bumping versions", "writing release notes", "tagging a release", "publishing") are supplemented with natural colloquial variations users would actually say: "let's ship", "prep a release", "what's changed since last release", "time to cut a new version". Coverage of natural terms including synonyms matches the 5 anchor; 4 would mean a few natural terms are missing, but both formal and casual phrasings are present.

5 / 5

Distinctiveness Conflict Risk

The niche is clear (Plannotator's release process, anchored by the project name and "tag-driven release pipeline"), but trigger phrases like "bump versions", "publishing", and "prep a release" are generic release vocabulary that could overlap with release/changelog skills for other projects in a multi-project setup. This fits the 4 anchor (mostly distinct, minor overlap risk); 5 would require minimal conflict risk, but the colloquial triggers are not project-qualified, and 3 would imply overlap with broadly similar skills beyond just closely related release skills.

4 / 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

relative_links

Relative link issues: 3 missing

Warning

referenced_paths_exist

Referenced path issues: 6 missing, 1 deeper-than-1-level

Warning

Total

14

/

16

Passed

Repository

backnotprop/plannotator

Path

.agents/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.