changelog-designlisted

Use when preparing release changelogs, migration guides, or breaking change communication for consumers. Covers change categorization, before/after documentation, migration step authoring, semver version strategy, and release communication planning. Do not use for documentation architecture planning (use documentation-plan) or recording architectural decisions (use adr-template).
dtsong/my-claude-setup · ★ 5 · AI & Automation · score 76

Install: claude install-skill dtsong/my-claude-setup

# Changelog Design ## Purpose Create structured changelog entries and migration guides that enable consumers to understand changes, assess impact, and upgrade safely. Produces versioned changelogs following Keep a Changelog format with step-by-step migration instructions for breaking changes. ## Scope Constraints Reads commit history, PR descriptions, and existing changelog entries to produce release documentation. Does not modify source code, bump version numbers, or publish releases. ## Inputs - List of changes (commits, PRs, or feature descriptions) - Current version number - Consumer types (library users, API consumers, internal teams) - Previous changelog entries (for format consistency) ## Input Sanitization No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets. ## Procedure ### Progress Checklist - [ ] Step 1: Categorize all changes - [ ] Step 2: Describe each change with full context - [ ] Step 3: Write migration steps for breaking changes - [ ] Step 4: Define version strategy - [ ] Step 5: Plan communication - [ ] Step 6: Validate migration path ### Step 1: Categorize All Changes Classify each change by impact: - **Breaking**: Requires consumer action to upgrade — API changes, removed features, changed behavior - **Feature**: New capability with no impact on existing behavior — additive APIs, new options - **Fix**: Bug resolution — corrected behavior, error handling improvements - **Deprecation**: