How do I install the Changelog 1 1 0 skill?

Run npx skillmds@latest add tangledgroup/changelog-1-1-0 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Changelog 1 1 0 safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Changelog 1 1 0?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Changelog 1 1 0 free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Changelog 1 1 0?

tangledgroup (@tangledgroup) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Changelog 1 1 0 by tangledgroup — Agent Skill

Name: Changelog 1 1 0
Author: tangledgroup

Changelog 1 1 0

Create and maintain changelogs following the Keep a Changelog specification v1.1.0, providing standardized format guidelines, best practices, and examples for documenting project changes in a human-readable way. Use when creating release notes, documenting version changes, maintaining CHANGELOG.md files, or formatting project updates following the official specification.

tangledgroup Updated Sep 17, 2026

File contents

Keep a Changelog 1.1.0

Overview

A changelog is a file containing a curated, chronologically ordered list of notable changes for each version of a project. The Keep a Changelog specification (v1.1.0) defines conventions for writing human-readable changelogs that make it easy for users and contributors to see precisely what notable changes have been made between releases.

This skill covers the complete Keep a Changelog format, its guiding principles, types of changes, bad practices to avoid, frequently asked questions, and the Semantic Versioning 2.0.0 specification that changelog versions should follow.

When to Use

Creating a new CHANGELOG.md for a project
Maintaining or updating an existing changelog
Writing release notes that follow standardized conventions
Understanding how version numbers relate to types of changes
Converting git commit logs into proper human-readable changelog entries
Deciding whether a change warrants a major, minor, or patch version bump
Validating changelog format against the specification

Core Concepts

Changelog: A curated file (typically CHANGELOG.md) listing notable changes per version, written for humans not machines.

Version entry: Each release gets its own section with a version number and release date in ISO 8601 format (YYYY-MM-DD).

Change types: Changes are categorized into six standard types — Added, Changed, Deprecated, Removed, Fixed, Security — each signaling a different kind of modification to end users.

Semantic Versioning (SemVer): The versioning scheme (MAJOR.MINOR.PATCH) that changelog entries should follow, where the version number communicates the nature and impact of changes.

Unreleased section: A top-of-file section for tracking upcoming changes before they are released, serving as both a development log and release preparation tool.

Example Format

A minimal changelog following the specification:

# 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]

## [1.0.0] - 2024-01-15

### Added

- User authentication with OAuth2
- REST API endpoints for resource management

### Changed

- Upgraded database driver from v3 to v4

### Fixed

- Memory leak in background worker process

With Markdown link references at the bottom:

[unreleased]: https://github.com/example/project/compare/v1.0.0...HEAD
[1.0.0]: https://github.com/example/project/compare/v0.9.0...v1.0.0

Advanced Topics

Format Specification: Complete changelog format rules, change types, and Markdown structure → Format Specification

Semantic Versioning 2.0.0: Full SemVer specification covering version format, precedence rules, pre-release and build metadata → Semantic Versioning 2.0.0

Best Practices and FAQ: Guiding principles, bad practices to avoid, effort reduction tips, and frequently asked questions → Best Practices and FAQ

---name: changelog-1-1-0description: Create and maintain changelogs following the Keep a Changelog specification v1.1.0, providing standardized format guidelines, best practices, and examples for documenting project changes in a human-readable way. Use when creating release notes, documenting version changes, maintaining CHANGELOG.md files, or formatting project updates following the official specification.---# Keep a Changelog 1.1.0## OverviewA changelog is a file containing a curated, chronologically ordered list of notable changes for each version of a project. The Keep a Changelog specification (v1.1.0) defines conventions for writing human-readable changelogs that make it easy for users and contributors to see precisely what notable changes have been made between releases.This skill covers the complete Keep a Changelog format, its guiding principles, types of changes, bad practices to avoid, frequently asked questions, and the Semantic Versioning 2.0.0 specification that changelog versions should follow.## When to Use- Creating a new `CHANGELOG.md` for a project- Maintaining or updating an existing changelog- Writing release notes that follow standardized conventions- Understanding how version numbers relate to types of changes- Converting git commit logs into proper human-readable changelog entries- Deciding whether a change warrants a major, minor, or patch version bump- Validating changelog format against the specification## Core Concepts**Changelog**: A curated file (typically `CHANGELOG.md`) listing notable changes per version, written for humans not machines.**Version entry**: Each release gets its own section with a version number and release date in ISO 8601 format (`YYYY-MM-DD`).**Change types**: Changes are categorized into six standard types — Added, Changed, Deprecated, Removed, Fixed, Security — each signaling a different kind of modification to end users.**Semantic Versioning (SemVer)**: The versioning scheme (`MAJOR.MINOR.PATCH`) that changelog entries should follow, where the version number communicates the nature and impact of changes.**Unreleased section**: A top-of-file section for tracking upcoming changes before they are released, serving as both a development log and release preparation tool.## Example FormatA minimal changelog following the specification:```markdown# ChangelogAll 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]## [1.0.0] - 2024-01-15### Added- User authentication with OAuth2- REST API endpoints for resource management### Changed- Upgraded database driver from v3 to v4### Fixed- Memory leak in background worker process```With Markdown link references at the bottom:```markdown[unreleased]: https://github.com/example/project/compare/v1.0.0...HEAD[1.0.0]: https://github.com/example/project/compare/v0.9.0...v1.0.0```## Advanced Topics**Format Specification**: Complete changelog format rules, change types, and Markdown structure → [Format Specification](reference/01-format-specification.md)**Semantic Versioning 2.0.0**: Full SemVer specification covering version format, precedence rules, pre-release and build metadata → [Semantic Versioning 2.0.0](reference/02-semantic-versioning.md)**Best Practices and FAQ**: Guiding principles, bad practices to avoid, effort reduction tips, and frequently asked questions → [Best Practices and FAQ](reference/03-best-practices-faq.md)

Frequently asked questions