domains / software-engineering / changelog-generation / changelog-generator

changelog-generator

Skill card

combined

The copies split into two distinct procedures. Three copies (davepoon, Prat011, ComposioHQ) are identical prompt-style skills that instruct the agent to scan git history, categorize changes, and translate them into user-friendly notes. The LeoYeAI copy is a script-based engineering skill that relies on specific Python scripts (generate_changelog.py, commit_linter.py), enforces Conventional Commits, and handles SemVer bumping. Because the LeoYeAI copy contains material steps (script execution, linting, SemVer logic) that the others lack, and the others contain a natural-language workflow that the script-based copy does not explicitly describe as a prompt, crowning one would hide a real alternative implementation.

Repositories

Other copies

Combined skill

---
name: changelog-generator
description: Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes.
---

# Changelog Generator

This skill transforms technical git commits into polished, user-friendly changelogs. It supports both a natural-language workflow for quick generation and a script-based workflow for automated, CI-integrated release management.

## When to Use This Skill

- Preparing release notes for a new version
- Creating weekly or monthly product update summaries
- Documenting changes for customers
- Writing changelog entries for app store submissions
- Generating update notifications
- Creating internal release documentation
- Maintaining a public changelog/product updates page

## Workflow Options

### Option 1: Natural Language Generation
Use this when you want the agent to analyze commits and write the changelog directly.

1. **Scan Git History**: Analyze commits from a specific time period or between versions.
2. **Categorize Changes**: Group commits into logical categories (features, improvements, bug fixes, breaking changes, security).
3. **Translate Technical → User-Friendly**: Convert developer commits into customer language.
4. **Format Professionally**: Create clean, structured changelog entries.
5. **Filter Noise**: Exclude internal commits (refactoring, tests, etc.).

**Example Prompt**:
```
Create a changelog for commits since v2.4.0, using my changelog guidelines from CHANGELOG_STYLE.md
```

### Option 2: Script-Based Automation (Conventional Commits)
Use this when you have a repository with Conventional Commits and want automated, auditable release notes.

1. **Lint Commits**: Validate commit format before generation.
   ```bash
   python3 scripts/commit_linter.py --from-ref origin/main --to-ref HEAD --strict
   ```
2. **Generate Changelog**: Run the generator script to parse commits and render markdown.
   ```bash
   python3 scripts/generate_changelog.py \
     --from-tag v1.3.0 \
     --to-tag v1.4.0 \
     --next-version v1.4.0 \
     --format markdown
   ```
3. **Update CHANGELOG.md**: Prepend the new entry to the changelog file.
   ```bash
   python3 scripts/generate_changelog.py \
     --from-tag v1.3.0 \
     --to-tag HEAD \
     --next-version v1.4.0 \
     --write CHANGELOG.md
   ```

## Conventional Commit Rules (for Script-Based Workflow)

- **Supported Types**: `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore`, `security`, `deprecated`, `remove`.
- **Breaking Changes**: Indicated by `!` after type/scope or `BREAKING CHANGE:` in footer.
- **SemVer Mapping**:
  - Breaking change -> `major`
  - Non-breaking `feat` -> `minor`
  - All others -> `patch`

## Best Practices

- Run from your git repository root.
- Specify date ranges or version tags for focused changelogs.
- Use a `CHANGELOG_STYLE.md` for consistent formatting.
- Review and adjust the generated changelog before publishing.
- Keep commits small and intent-driven.
- Scope commit messages (`feat(api): ...`) in multi-package repos.
- Enforce linter checks in PR pipelines if using the script-based workflow.
- Tag releases only after changelog generation succeeds.

## Output Quality Checks

- Each bullet is user-meaningful, not implementation noise.
- Breaking changes include migration action.
- Security fixes are isolated in a `Security` section.
- Sections with no entries are omitted.
- Duplicate bullets across sections are removed.