Automate changelog generation from commits, PRs, and releases following Keep a Changelog format. Use when setting up release workflows, generating release notes, or standardizing commit conventions.
76
64%
Does it follow best practices?
Impact
100%
1.25xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-wshobson/documentation-generation/skills/changelog-automation/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly communicates its purpose, lists concrete actions, includes natural trigger terms, and has an explicit 'Use when' clause. It follows third-person voice correctly and occupies a distinct niche that would be easy to differentiate from other skills. The description is concise yet comprehensive.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'changelog generation from commits, PRs, and releases', 'setting up release workflows', 'generating release notes', 'standardizing commit conventions'. Also references a specific format standard (Keep a Changelog). | 3 / 3 |
Completeness | Clearly answers both 'what' (automate changelog generation from commits, PRs, and releases following Keep a Changelog format) and 'when' (explicit 'Use when' clause covering release workflows, release notes, and commit conventions). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'changelog', 'commits', 'PRs', 'releases', 'release notes', 'release workflows', 'commit conventions', 'Keep a Changelog'. These cover common variations of how users would describe this need. | 3 / 3 |
Distinctiveness Conflict Risk | Occupies a clear niche around changelog generation and release note automation. The specific mention of Keep a Changelog format, commits, PRs, and release workflows makes it highly distinguishable from general git or documentation skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
29%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive reference dump rather than an actionable guide. While the individual code blocks are executable and well-formed, the sheer volume (6 methods, 2 templates, examples, best practices) makes it a poor skill file—it's more of a wiki article. It lacks workflow sequencing, validation steps, and any guidance on choosing between the many presented approaches.
Suggestions
Reduce to 1-2 recommended methods (e.g., semantic-release for full automation, git-cliff for lightweight) and move others to separate reference files linked from the main skill.
Add a clear decision tree or workflow: 'Choose Method → Install → Configure → Validate Setup → First Release → Ongoing Usage' with explicit validation checkpoints at each stage.
Remove the Core Concepts section (Keep a Changelog format, Conventional Commits spec, semver explanation)—Claude already knows these standards. Replace with a one-line reference link if needed.
Fix the GitHub Actions workflow bug where `steps.version.outputs.tag` is referenced but never defined, and add validation steps (e.g., dry-run before actual release).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. Includes 6 different methods (standard-version, semantic-release, git-cliff, commitizen, GitHub Actions, conventional changelog) when 1-2 would suffice. Explains Conventional Commits format, semver, and Keep a Changelog format which Claude already knows. The release notes templates, commit message examples, and best practices sections add significant bulk without proportional value. | 1 / 3 |
Actionability | Highly actionable with fully executable code blocks, complete configuration files, and copy-paste ready commands across multiple tools. Each method includes installation commands, configuration files, and usage examples that are concrete and specific. | 3 / 3 |
Workflow Clarity | Despite presenting 6 different methods, there is no clear workflow sequence for any of them. Steps are not numbered or sequenced within methods (except bare install commands). No validation checkpoints, no error recovery guidance, and no guidance on which method to choose when. The GitHub Actions workflow has a bug (references steps.version.outputs.tag which is never defined). | 1 / 3 |
Progressive Disclosure | Monolithic wall of content with everything inline. Six complete tool configurations, two release note templates, commit examples, best practices, and external resources are all dumped into a single file. This content should be split across multiple files (e.g., separate files per tool/method) with the SKILL.md serving as an overview with links. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (581 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
6e3d68c
Table of Contents
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.