47 lines
1.6 KiB
Markdown
47 lines
1.6 KiB
Markdown
---
|
|
name: changelog-automation
|
|
description: "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."
|
|
risk: unknown
|
|
source: community
|
|
date_added: "2026-02-27"
|
|
---
|
|
|
|
# Changelog Automation
|
|
|
|
Patterns and tools for automating changelog generation, release notes, and version management following industry standards.
|
|
|
|
## Use this skill when
|
|
|
|
- Setting up automated changelog generation
|
|
- Implementing conventional commits
|
|
- Creating release note workflows
|
|
- Standardizing commit message formats
|
|
- Managing semantic versioning
|
|
|
|
## Do not use this skill when
|
|
|
|
- The project has no release process or versioning
|
|
- You only need a one-time manual release note
|
|
- Commit history is unavailable or unreliable
|
|
|
|
## Instructions
|
|
|
|
- Select a changelog format and versioning strategy.
|
|
- Enforce commit conventions or labeling rules.
|
|
- Configure tooling to generate and publish notes.
|
|
- Review output for accuracy, completeness, and wording.
|
|
- If detailed examples are required, open `resources/implementation-playbook.md`.
|
|
|
|
## Safety
|
|
|
|
- Avoid exposing secrets or internal-only details in release notes.
|
|
|
|
## Resources
|
|
|
|
- `resources/implementation-playbook.md` for detailed patterns, templates, and examples.
|
|
|
|
## Limitations
|
|
- Use this skill only when the task clearly matches the scope described above.
|
|
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
|
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|