add-to-changelog
Use when you've shipped a feature, fix, or breaking change and need to update CHANGELOG.md — follows Keep a Changelog format and syncs version numbers across package manifests.
Best use case
add-to-changelog is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when you've shipped a feature, fix, or breaking change and need to update CHANGELOG.md — follows Keep a Changelog format and syncs version numbers across package manifests.
Teams using add-to-changelog should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/add-to-changelog/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How add-to-changelog Compares
| Feature / Agent | add-to-changelog | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when you've shipped a feature, fix, or breaking change and need to update CHANGELOG.md — follows Keep a Changelog format and syncs version numbers across package manifests.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Add to Changelog
## When to Use
- After completing a feature, fix, or breaking change ready for release
- Before tagging a new version — to ensure CHANGELOG is current
- During release prep — to create a new version section with today's date
- As part of `commit-workflow` → `add-to-changelog` → `release` pipeline
## Prerequisites
- Git repository with meaningful commit history
- `CHANGELOG.md` exists or will be created
- Version follows [Semantic Versioning](https://semver.org/) (`MAJOR.MINOR.PATCH`)
## Workflow
### 1. Locate or Create CHANGELOG.md
```powershell
# Check if CHANGELOG exists
if (-not (Test-Path CHANGELOG.md)) {
# Create with standard header
@"
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
"@ | Set-Content CHANGELOG.md
}
```
### 2. Determine the Change Type
| Type | Use for |
|------|---------|
| `Added` | New features, new capabilities |
| `Changed` | Changes to existing functionality |
| `Deprecated` | Features that will be removed in a future release |
| `Removed` | Features that were removed in this release |
| `Fixed` | Bug fixes |
| `Security` | Vulnerability fixes |
### 3. Add Entry to the Right Section
**Option A — Add to `[Unreleased]` (staging for next release):**
```powershell
# Read current CHANGELOG
$changelog = Get-Content CHANGELOG.md -Raw
# Insert under [Unreleased] → Added section
$entry = "- Your change description here"
$changelog = $changelog -replace '(## \[Unreleased\]\s*\n)', "`$1`n### Added`n$entry`n"
Set-Content CHANGELOG.md $changelog
```
**Option B — Create a new versioned section:**
```powershell
$version = "1.2.0"
$date = Get-Date -Format "yyyy-MM-dd"
$newSection = @"
## [$version] - $date
### Added
- New feature description
"@
$changelog = Get-Content CHANGELOG.md -Raw
$changelog = $changelog -replace '(## \[Unreleased\])', "$newSection`$1"
Set-Content CHANGELOG.md $changelog
```
### 4. Sync Version in Package Manifests
```powershell
$version = "1.2.0"
# Node.js
if (Test-Path package.json) {
$pkg = Get-Content package.json | ConvertFrom-Json
$pkg.version = $version
$pkg | ConvertTo-Json -Depth 10 | Set-Content package.json
}
# Python (pyproject.toml)
if (Test-Path pyproject.toml) {
(Get-Content pyproject.toml) -replace 'version = ".*"', "version = `"$version`"" |
Set-Content pyproject.toml
}
```
### 5. Commit the Changelog Update
```powershell
git add CHANGELOG.md package.json # or pyproject.toml
git commit -m "📝 docs(changelog): add v$version release notes"
```
## Examples
### Full Release Entry
```markdown
## [2.1.0] - 2026-03-29
### Added
- Conventional commit workflow skill with emoji mapping
- Multi-perspective PR review (PM / Dev / QA / Security / DevOps / UX)
- Context priming skill for session initialization
### Changed
- Migration guide updated: Hooks terminology corrected to "alternative" not "equivalent"
### Fixed
- Incorrect frontmatter category in security-scan skill
### Security
- Evaluate-repository skill now enforces read-only analysis mode by default
```
### Keep Changelog Format
```markdown
## [Unreleased] ← work in progress, no date
## [2.1.0] - 2026-03-29 ← released version with date
## [2.0.0] - 2026-01-15
```
## Tips
- **Write for humans, not machines**: CHANGELOG entries should explain *what changed for users*, not internal implementation details
- **One entry per user-visible change**: don't combine unrelated fixes in one bullet
- **Link versions**: add `[2.1.0]: https://github.com/owner/repo/compare/v2.0.0...v2.1.0` at the bottom for diff links
- **Unreleased as staging area**: keep changes in `[Unreleased]` until a version is cut
- **Automation option**: `git cliff` or `conventional-changelog` can auto-generate entries from Conventional Commits
## See Also
- [`commit-workflow`](../../workflow/commit-workflow/SKILL.md) — write good commit messages first
- [`doc-update`](../doc-update/SKILL.md) — update broader documentation
- [Keep a Changelog](https://keepachangelog.com/)
- *Inspired by: [awesome-claude-code/resources/slash-commands/add-to-changelog](https://github.com/hesreallyhim/awesome-claude-code)*Related Skills
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.