From bmad-utility-skills
Analyzes commits and PRs since last release to draft CHANGELOG.md updates. Use for 'update the changelog' or 'prepare release notes' requests.
How this skill is triggered — by the user, by Claude, or both
Slash command
/bmad-utility-skills:bmad-os-draft-changelogThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**This skill ONLY updates CHANGELOG.md. That is its entire purpose.**
This skill ONLY updates CHANGELOG.md. That is its entire purpose.
Releases are handled by each repo's GitHub Actions release workflow. Your job ends once CHANGELOG.md is updated. After the user merges the changelog change, suggest they run the release workflow via gh workflow run (or via the Actions UI) — but never trigger it yourself.
Project path (or run from project root)
Look for .claude-plugin/marketplace.json in the project root. If found, read it to understand plugin versioning:
{
"plugins": [
{ "name": "plugin-a", "version": "1.2.0" },
{ "name": "plugin-b", "version": "2.0.1" }
]
}
Single plugin: Use its version as the changelog version. Confirm with the user: "marketplace.json shows plugin-name at vX.Y.Z. Drafting changelog for this version - correct?"
Multiple plugins: Ask the user which plugin(s) need changelog entries and what the new version(s) will be. Each plugin gets its own section in the changelog (see Step 3 format).
No marketplace.json found: Fall back to git tags for versioning (original behavior).
Use thoroughness: "very thorough" to analyze all changes since the last release tag.
Key: For each merge commit, look up the merged PR/issue that was closed.
gh pr view or git commit body to find the PR numberAnalyze:
Provide:
Single-plugin or tag-based repos:
## vX.Y.Z - [Date]
* [Change 1 - categorized by type]
* [Change 2]
Multi-plugin repos (when marketplace.json has multiple plugins):
## plugin-name - vX.Y.Z - [Date]
* [Change 1 - categorized by type]
* [Change 2]
## other-plugin - vA.B.C - [Date]
* [Change 3]
Each plugin gets its own H2 section. Only include plugins that actually have changes. Changes that affect shared code or the repo generally should be listed under whichever plugin(s) they impact.
Guidelines:
Show the draft with current version, last tag, commit count, and options to edit/retry.
When user accepts:
# Changelog header) and open the file for the user to review the changes.gh workflow run publish.yaml --ref main
Adjust the workflow filename to match what's in .github/workflows/ (commonly publish.yaml or release.yaml). If the workflow takes inputs (channel, bump type), include them — e.g. -f channel=latest -f bump=minor.DO NOT:
npx claudepluginhub bmad-code-org/bmad-utility-skills --plugin bmad-utility-skillsCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.