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.

8 stars

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

$curl -o ~/.claude/skills/add-to-changelog/SKILL.md --create-dirs "https://raw.githubusercontent.com/drvoss/everything-copilot-cli/main/skills/documentation/add-to-changelog/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/add-to-changelog/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How add-to-changelog Compares

Feature / Agentadd-to-changelogStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly

triage

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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.