What happens if CHANGELOG.md doesn't exist?

The skill creates a template in the project root with an [Unreleased] section and the standard Added/Changed/Fixed categories.

How are commits turned into changelog entries?

The skill parses commit type, scope, and description, maps the type to a category per the table, and adds a one-line entry under [Unreleased] with the current date.

Can I release a new version with this skill?

Yes. On release, it moves Unreleased entries to a new [X.Y.Z] section with a date, then creates a fresh [Unreleased] section for future changes.

Project Change Log

npx machina-cli add skill hackermanishackerman/claude-skills-vault/project-change-log --openclaw

Files (1)

SKILL.md

3.9 KB

Project Change Log

Automatically maintain a CHANGELOG.md file following the Keep a Changelog standard.

When to Use

After creating a commit
When /commit command is executed
When user asks to update changelog
When releasing a new version

Changelog Format

The standard format is CHANGELOG.md in the project root, following Keep a Changelog:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/),
and this project adheres to [Semantic Versioning](https://semver.org/).

## [Unreleased]

### Added
- New feature description

### Changed
- Change description

### Fixed
- Bug fix description

## [1.0.0] - 2026-01-04

### Added
- Initial release features

Change Categories

Category	Description
Added	New features
Changed	Changes in existing functionality
Deprecated	Soon-to-be removed features
Removed	Removed features
Fixed	Bug fixes
Security	Vulnerability fixes

Process

1. Detect Changelog

Check if CHANGELOG.md exists in project root:

If exists: Read current content
If not: Create with template

2. Analyze Commit

Extract from the commit:

Type: feat, fix, docs, etc.
Scope: Affected area
Description: What changed
Date: Current date (YYYY-MM-DD)
Author: From git config

3. Map Commit Type to Category

Commit Type	Changelog Category
`feat`	Added
`fix`	Fixed
`docs`	Changed
`style`	Changed
`refactor`	Changed
`perf`	Changed
`test`	Changed
`build`	Changed
`ci`	Changed
`chore`	Changed
`security`	Security
`deprecate`	Deprecated
`remove`	Removed

4. Update Changelog

Add entry under [Unreleased] section in appropriate category:

## [Unreleased]

### Added
- New entry here with description

5. Version Release

When releasing a version:

Move [Unreleased] content to new version section
Add version number and date
Create new empty [Unreleased] section

Entry Format

Each entry should be:

One line per change
Start with capital letter
No period at end
Include scope if relevant: **scope**: description

Examples:

### Added
- **auth**: OAuth2 login with Google and GitHub
- User profile settings page
- Dark mode toggle

### Fixed
- **api**: Handle null response in user endpoint
- Memory leak in websocket connections

Template

Initial CHANGELOG.md template:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/),
and this project adheres to [Semantic Versioning](https://semver.org/).

## [Unreleased]

### Added

### Changed

### Fixed

Integration with Commit

After each commit:

Parse commit message for type and description
Determine changelog category
Add entry under [Unreleased]
Stage CHANGELOG.md (do not create separate commit)

Examples

Example 1: Feature Commit

Commit: feat(auth): add OAuth2 login support

Changelog Entry:

### Added
- **auth**: OAuth2 login support

Example 2: Bug Fix

Commit: fix(api): handle null response in user endpoint

Changelog Entry:

### Fixed
- **api**: Handle null response in user endpoint

Example 3: Version Release

Before:

## [Unreleased]

### Added
- Feature A
- Feature B

### Fixed
- Bug fix X

After releasing v1.2.0:

## [Unreleased]

## [1.2.0] - 2026-01-04

### Added
- Feature A
- Feature B

### Fixed
- Bug fix X

Source

git clone https://github.com/hackermanishackerman/claude-skills-vault/blob/main/.claude/skills/project-change-log/SKILL.md

View on GitHub

Overview

This skill automatically maintains a project's CHANGELOG.md in the root, following Keep a Changelog. It detects when to update, parses commits, and writes entries under the Unreleased section to prep for releases.

How This Skill Works

It checks for CHANGELOG.md in the project root and creates a template if missing. It analyzes commits to extract Type, Scope, Description, and Date, maps the Type to a category using the provided table, and updates the Unreleased section accordingly. For releases, it moves Unreleased content to a new version section, adds the version and date, and starts a fresh Unreleased section.

When to Use It

After creating a commit
When `/commit` command is executed
When user asks to update changelog
When releasing a new version
During automated release pipelines to prep changelog entries

Quick Start

Step 1: Ensure CHANGELOG.md exists in the project root (create if missing).
Step 2: When committing, extract type, scope, description, and date to determine the changelog entry.
Step 3: Update the [Unreleased] section under the appropriate category and stage the file (do not commit yet).

Best Practices

Keep Unreleased sections organized by category (Added, Changed, Fixed, etc.)
Use the Type/Scope/Description format for each entry
Capitalize the first letter and omit trailing periods
Date each version release accurately
Stage changes to CHANGELOG.md without creating a separate commit

Example Use Cases

OAuth2 login with Google and GitHub
User profile settings page
Dark mode toggle
API: Handle null response in user endpoint
Memory leak in websocket connections

Frequently Asked Questions

Add this skill to your agents