Skills changelog-automation
📦

changelog-automation

Safe

Automate Changelog Generation and Release Workflows

Managing changelogs manually is error-prone and time-consuming. This skill provides patterns and tools for automating changelog generation, release notes, and version management following industry standards like Keep a Changelog and Conventional Commits.

Supports: Claude Codex Code(CC)
📊 69 Adequate
1

Download the skill ZIP

2

Upload in Claude

Go to Settings → Capabilities → Skills → Upload skill

3

Toggle on and start using

Test it

Using "changelog-automation". Show me a basic Keep a Changelog template

Expected outcome:

A markdown template with sections for Unreleased, Added, Changed, Deprecated, Removed, Fixed, and Security, following the keepachangelog.com specification with proper semantic versioning links.

Using "changelog-automation". What are the Conventional Commit types I should use?

Expected outcome:

  • feat: New features (triggers MINOR version bump)
  • fix: Bug fixes (triggers PATCH version bump)
  • docs: Documentation changes (no version bump)
  • refactor: Code restructuring (maps to Changed section)
  • perf: Performance improvements (maps to Changed section)
  • test: Test additions (no version bump)
  • chore: Maintenance tasks (no version bump)

Using "changelog-automation". Configure git-cliff for my Rust project

Expected outcome:

A complete cliff.toml configuration file with conventional commits parsing, GitHub integration, and templated changelog sections formatted according to Keep a Changelog standards.

Security Audit

Safe
v5 • 1/21/2026

This skill contains documentation and configuration templates for changelog automation tools. All static findings are false positives: network URLs are documentation references to keepachangelog.com and semver.org, backtick patterns are code examples in markdown format, and env_access references are configuration samples for GitHub Actions workflows. No executable code or security risks detected.

2
Files scanned
1,378
Lines analyzed
0
findings
5
Total audits
No security issues found
Audited by: claude View Audit History →

Quality Score

38
Architecture
100
Maintainability
87
Content
22
Community
100
Security
87
Spec Compliance

What You Can Build

New Project Release Setup

Set up automated changelog generation for a new Node.js project using standard-version, commitlint, and GitHub Actions for consistent release workflows.

Migrating to Conventional Commits

Migrate an existing project to Conventional Commits standard with validation, automated versioning, and changelog generation to improve release consistency.

Multi-Language Release Automation

Configure changelog automation for projects in different languages using appropriate tools like semantic-release for Node.js or commitizen for Python.

Try These Prompts

Basic Changelog Setup 
Help me set up a CHANGELOG.md file following Keep a Changelog format for my project
Configure Conventional Commits 
Configure commitlint and husky to enforce Conventional Commits in my Node.js project
Automate Release Workflow 
Create a GitHub Actions workflow that automatically generates changelogs and creates releases using semantic-release
Custom Release Configuration 
Configure standard-version with custom commit types and changelog sections specific to my project structure

Best Practices

  • Use commitlint with husky to validate commit messages before they are created, preventing invalid commits from entering the repository
  • Configure separate workflows for manual and automatic releases to support both scheduled releases and emergency hotfixes
  • Define clear commit type conventions in team documentation and configure parsers to match your specific workflow needs

Avoid

  • Do not manually edit generated CHANGELOG.md files as changes will be overwritten on next automated release
  • Avoid mixing multiple unrelated changes in a single commit, which makes automated categorization inaccurate
  • Do not skip commitlint validation during development as it leads to inconsistent changelogs and broken automation

Frequently Asked Questions

What is the difference between standard-version and semantic-release?
standard-version requires manual triggering and gives you control over when releases happen, while semantic-release fully automates releases based on commit messages in CI/CD. Use standard-version for manual release approval, semantic-release for complete automation.
How do I handle breaking changes in my commits?
Add an exclamation mark after the type (feat!) or include BREAKING CHANGE: in the commit footer. This triggers a MAJOR version bump and highlights the change prominently in the changelog.
Can I customize which commit types appear in the changelog?
Yes, all tools support customization. In standard-version use .versionrc.js, in semantic-release use commit-analyzer options, and in git-cliff use commit_parsers in cliff.toml. Set hidden: true or skip: true to exclude types.
Which tool should I use for a Python project?
Use commitizen for Python projects. It integrates with pyproject.toml, supports interactive commits, and can update version files in Python packages automatically.
How do I migrate an existing project to Conventional Commits?
Start by adding commitlint configuration and husky hooks, then use changelog_start_rev to begin tracking from a specific version. Previous commits can remain in old format while new commits follow the convention.
What permissions do GitHub Actions need for automated releases?
The workflow needs contents: write permission to create releases and commits, and may need pull-requests: write for release PRs. Use GITHUB_TOKEN for basic operations and NPM_TOKEN only if publishing to npm registry.

Developer Details

Author

wshobson

License

MIT

Repository

https://github.com/wshobson/agents/tree/main/plugins/documentation-generation/skills/changelog-automation

Ref

main

File structure

📄 SKILL.md