changelog-automation

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.

1.25x

Quality

60%

Does it follow best practices?

Impact

100%

1.25x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./tests/ext_conformance/artifacts/agents-wshobson/documentation-generation/skills/changelog-automation/SKILL.md

The canonical home for this skill is changelog-automation in wshobson/agents

Quality

Content

50%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.

This is a config-recipe compendium: highly concrete tool setups undermined by verbosity and a monolithic structure. The body also contains executable errors in the GitHub release job and offers no guidance for selecting among the six competing methods.

Suggestions

Split each tool's full configuration (standard-version, semantic-release, git-cliff, commitizen) into per-tool files under references/ and keep SKILL.md as a decision-oriented overview of which method fits which situation.

Cut the background-knowledge sections — the Conventional Commits type table, SemVer explainer, and sample changelog — to a few lines or a pointer, since Claude already knows these standards.

Fix the GitHub release job: define a step with id 'version' to extract the tag (or use the pushed tag directly), generate RELEASE_NOTES.md before referencing it as body_path, and replace the Go-template-style release notes template with syntax an actual tool renders.

Dimension	Reasoning	Score
Conciseness	The body spends significant tokens on concepts Claude already knows — a full Conventional Commits type table, a SemVer MAJOR.MINOR.PATCH explainer, a complete sample changelog, and generic Do's/Don'ts — alongside six complete tool configs inlined in one file, making it noticeably verbose with several padded sections.	2 / 5
Actionability	Most content is executable and copy-paste ready (commitlint config, .versionrc.js, release.config.js, cliff.toml, pyproject.toml, GitHub Actions workflow), but there are concrete defects: the release job references ${{ steps.version.outputs.tag }} with no step id 'version', body_path: RELEASE_NOTES.md is never generated, and the GitHub Release Template uses Go-style {{ range .Features }} syntax no tool consumes.	4 / 5
Workflow Clarity	The six methods are each internally coherent but there is no sequencing or decision guidance for choosing among them, and release operations (publishing, pushing tags) — effectively irreversible batch actions — have no validation checkpoints, capping this dimension per the rubric's feedback-loop rule.	3 / 5
Progressive Disclosure	Section headers make the file navigable, but no bundle files exist (no references/, scripts/, or assets/) and everything — six full tool configurations, release note templates, commit examples — is inlined in a single ~575-line SKILL.md where clearly separate reference files belong.	3 / 5
	Total	12 / 20 Passed

Description

70%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 solid description with a clear what and an explicit 'Use when...' clause anchored to three concrete scenarios. Its main gaps are a single-action capability statement and missing natural trigger synonyms (CHANGELOG.md, version bump, semantic versioning).

Suggestions

Enumerate more of the skill's actual capabilities in the description — e.g., version bumping, release publishing, and commit linting — to raise specificity from one core action to several.

Add natural user-mention triggers such as 'CHANGELOG.md', 'version bump', or 'semantic versioning' so the when-clause covers how users actually phrase the need.

Dimension	Reasoning	Score
Specificity	"Automate changelog generation from commits, PRs, and releases" names the domain and one core action with its inputs, but does not enumerate several distinct concrete actions (no version bumping, publishing, or changelog linting), matching the 'names domain and 1-2 concrete actions' anchor rather than the 'several specific actions' anchor.	3 / 5
Completeness	It answers both parts — what ("Automate changelog generation from commits, PRs, and releases following Keep a Changelog format") and when ("Use when setting up release workflows, generating release notes, or standardizing commit conventions") — but the when clause covers setup scenarios only and lacks direct user-mention triggers like "when the user asks for a changelog", so it is not the fully concrete anchor 5.	4 / 5
Trigger Term Quality	"release workflows", "release notes", "commit conventions", and "commits, PRs, and releases" are natural phrases users would say, giving good keyword coverage; common synonyms like "CHANGELOG.md", "version bump", or "semantic versioning" are missing, so it falls short of the comprehensive-synonyms anchor.	4 / 5
Distinctiveness Conflict Risk	Changelog/release automation following Keep a Changelog is a clear niche unlikely to mis-trigger, with only minor overlap risk against general commit-message or git skills.	4 / 5
	Total	15 / 20 Passed

Validation

93%

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 — 15 / 16 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	15 / 16 Passed

Repository: Dicklesworthstone/pi_agent_rust
Path: tests/ext_conformance/artifacts/agents-wshobson/documentation-generation/skills/changelog-automation/SKILL.md
Commit: a65ce00

Reviewed: 6 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.