changelog-generator
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
59
37%
Does it follow best practices?
Impact
99%
1.03xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/all-skills/skills/changelog-generator/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is strong in specificity and distinctiveness, clearly articulating what the skill does and carving out a unique niche around changelog generation from git history. However, it lacks an explicit 'Use when...' clause, which limits its completeness score, and could benefit from broader trigger term coverage to catch more natural user phrasings.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to generate a changelog, write release notes, summarize recent commits, or prepare a CHANGELOG.md for a new version.'
Include additional trigger term variations such as 'CHANGELOG.md', 'change log', 'version notes', 'release summary', 'what's new', and 'release documentation'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'analyzing commit history', 'categorizing changes', 'transforming technical commits into clear, customer-friendly release notes'. These are concrete, well-defined capabilities. | 3 / 3 |
Completeness | Clearly answers 'what does this do' with detailed capability descriptions, but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied from the description of capabilities, which per the rubric caps completeness at 2. | 2 / 3 |
Trigger Term Quality | Includes good terms like 'changelogs', 'git commits', 'release notes', and 'commit history', but misses common variations users might say such as 'CHANGELOG.md', 'what changed', 'version notes', 'release summary', or 'change log' (two words). | 2 / 3 |
Distinctiveness Conflict Risk | The combination of git commits, changelogs, and customer-friendly release notes creates a very clear niche. This is unlikely to conflict with general git skills, documentation skills, or other writing skills due to its specific focus on changelog generation. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
7%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads more like a marketing description or README than an actionable skill for Claude. It explains what a changelog generator does conceptually but provides zero executable implementation—no git commands, no parsing logic, no categorization rules, no templates. The example output is helpful but insufficient without the concrete steps to produce it.
Suggestions
Add concrete git commands for extracting commit history (e.g., `git log --oneline v2.4.0..HEAD`) and show how to parse the output
Provide explicit categorization rules with patterns (e.g., commits starting with 'feat:' → New Features, 'fix:' → Bug Fixes) rather than just describing that categorization happens
Include a concrete workflow: 1) run git log command, 2) parse and categorize commits, 3) transform to user-friendly language with specific rewriting rules, 4) format output using a provided template
Remove the 'When to Use This Skill', 'Related Use Cases', and 'Tips' sections—they consume tokens without adding actionable guidance Claude needs
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Heavily padded with unnecessary content. The 'When to Use This Skill' section lists 7 obvious use cases Claude doesn't need. 'What This Skill Does' explains the concept rather than instructing. 'Tips' and 'Related Use Cases' sections add little actionable value. Much of this is describing rather than instructing. | 1 / 3 |
Actionability | No executable code, no git commands, no concrete implementation steps. The 'How to Use' section just shows natural language prompts rather than actual commands or scripts. There's no code for parsing git logs, no commit categorization logic, no regex patterns, no template structures—just a description of what the skill does and an example output. | 1 / 3 |
Workflow Clarity | The 'What This Skill Does' lists 6 conceptual steps but provides no actual workflow with concrete commands or validation checkpoints. There's no guidance on how to fetch commits (git log commands), how to categorize them, or how to verify the output. No feedback loops or error handling for edge cases like empty commit ranges or unconventional commit messages. | 1 / 3 |
Progressive Disclosure | The content is organized into clear sections with headers, which provides some structure. However, there are no bundle files or references to supporting documents. The content that exists is mostly filler rather than substantive material that would benefit from being split across files. References to CHANGELOG_STYLE.md are mentioned but not provided or explained. | 2 / 3 |
Total | 5 / 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 |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- davepoon/buildwithclaude
- Commit
d065ead
- 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.