write-release-notes

Generate engaging, high-energy release notes for a given version tag. Fetches the release from GitHub, retrieves every linked PR's title and description, then synthesizes all changes into a polished, user-facing release note with an enthusiastic tone. Use when the user asks to write, generate, or create release notes for a version (e.g. "write release notes for v1.32.0", "generate release notes for the latest release", "create changelog for v2.0").

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

85%Weight 40%Scale 1-3

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 workflow with executable bundled scripts and a clear validate-and-retry feedback loop. The main weakness is mild verbosity in the template placeholders and tone-guideline bullets that could be condensed without losing clarity.

Suggestions

Condense the bracketed instructional text inside the markdown template (e.g. '[2-4 sentence narrative...]', '[1-2 sentences expanding...]') into terse rules; the placeholders read as verbose meta-commentary.

Merge overlapping Tone & Style bullets — e.g. 'Be informative, not marketty' and 'Enthusiasm through substance' — to trim redundancy and shorten the bullet list.

The 'No implementation details' and 'No PR/issue references' bullets could be folded into a single 'Focus on user-facing changes only' rule to save tokens.

Dimension	Reasoning	Score
Conciseness	Mostly efficient and free of basic-concept explanations, but the markdown template's bracketed instructional placeholders and the 11-bullet Tone & Style section include redundancy (e.g. 'Be informative, not marketty' overlaps 'Enthusiasm through substance') that could be tightened; not a 1 because it never pads with concepts Claude already knows, and not a 3 because some tokens do not fully earn their place.	2 / 3
Actionability	Fully executable, copy-paste-ready commands referencing real bundle scripts ('bash .../fetch-release-data.sh <version> [owner/repo]', 'echo "<release notes>" \| bash .../validate-release-notes.sh'), a concrete categorization table, and a complete output template; not a 2 because guidance is complete and executable rather than pseudocode.	3 / 3
Workflow Clarity	Seven clearly numbered steps with an explicit validation checkpoint and feedback loop in step 6 (run validator → on FAIL trim → re-run until PASS) plus a concrete trim strategy; not a 2 because checkpoints are explicit, not implicit.	3 / 3
Progressive Disclosure	Heavy fetch and validation logic is externalized into two real, clearly-signaled one-level-deep scripts (verified to exist), and the body is well-organized into sequenced sections; not a 2 because references are clearly signaled and the split is appropriate rather than leaving content that should be separate inline.	3 / 3
	Total	11 / 12 Passed

Description

100%Weight 40%Scale 1-3

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, complete description that states concrete capabilities and gives explicit natural-language triggers with realistic example utterances. Third-person voice is maintained throughout, so no voice penalty applies.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'Fetches the release from GitHub, retrieves every linked PR's title and description, then synthesizes all changes' — matching the 'lists multiple specific concrete actions' anchor; not a 2 because the action set is comprehensive rather than partial. Minor fluff ('engaging, high-energy', 'enthusiastic tone') does not undermine the concrete action list.	3 / 3
Completeness	Explicitly answers both what (fetch release, retrieve PR details, synthesize into a release note) and when ('Use when the user asks to write, generate, or create release notes for a version'); not a 2 because the 'when' is explicit rather than implied.	3 / 3
Trigger Term Quality	Strong natural phrasing users would actually say: 'write release notes for v1.32.0', 'generate release notes for the latest release', 'create changelog for v2.0', with good variation across 'release notes' and 'changelog'; matches the 'good coverage of natural terms' anchor.	3 / 3
Distinctiveness Conflict Risk	A clear niche — GitHub release notes/version tags/PR synthesis — with distinct triggers unlikely to fire for unrelated skills; not a 2 because the scope is tightly bounded to release-note generation.	3 / 3
	Total	12 / 12 Passed

Validation

100%

Warnings & errors only

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: tailcallhq/forgecode
Path: .forge/skills/write-release-notes/SKILL.md
Commit: 1ca089a

Reviewed: 7 days ago

Table of Contents

Discovery Implementation Validation

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.