automated-changelog
LLM-powered automated changelog generation for Git repositories.
Overview
automated-changelog is a Python CLI tool that automatically generates human-readable changelogs by analyzing your Git history and using LLMs to create concise, meaningful summaries. It filters out noise to focus on significant changes.
Installation
pip install automated-changelog
Quick Start
-
Set up LLM credentials (create
.envfile in your repo):LITELLM_PROXY_API_BASE=https://your-litellm-proxy.example.com LITELLM_PROXY_API_KEY=sk-your-key-here
-
Initialize configuration (in your Git repo):
automated-changelog initThis creates
.changelog_config.yamlwith default settings. -
Generate your changelog:
# Preview without writing automated-changelog generate --dry-run # Generate and write to CHANGELOG.md automated-changelog generate # Skip LLM summarization (just list commits) automated-changelog generate --skip-llm
CLI Commands
automated-changelog init [--config PATH]
Creates a .changelog_config.yaml configuration file in your repository with sensible defaults for commit filtering and LLM summarization.
Example:
cd /path/to/your/repo
automated-changelog init
automated-changelog generate [OPTIONS]
Generates changelog entries from Git history since the last run.
Options:
--dry-run- Preview the changelog without writing to file--skip-llm- Skip LLM summarization and only list commits--config PATH- Use custom config file (default:.changelog_config.yaml)--from-date DATE- Start date for commits (YYYY-MM-DD) for historical generation--to-date DATE- End date for commits (YYYY-MM-DD) for historical generation
Examples:
# Preview before generating
automated-changelog generate --dry-run
# Generate with LLM summaries
automated-changelog generate
# Just list commits without LLM
automated-changelog generate --skip-llm
# Generate historical changelog for specific date range
automated-changelog generate --from-date 2024-01-01 --to-date 2024-01-07
# Generate changelog for all commits since a date
automated-changelog generate --from-date 2024-01-01
# Generate changelog for all commits until a date
automated-changelog generate --to-date 2024-12-31
Environment Variables
LITELLM_PROXY_API_BASE- Your LiteLLM proxy URLLITELLM_PROXY_API_KEY- Your LiteLLM API keySSL_VERIFY- Set tofalseto disable SSL verification (for internal proxies)
Example:
SSL_VERIFY=false automated-changelog generate --dry-run
Core Functionality
- Commit Analysis: Processes
git loghistory, focusing on commits since the last time the tool was run (tracked via metadata within theCHANGELOG.md). - Intelligent Filtering: Filters out minor commits (e.g., chores, docs, tests, typos) based on customizable rules (commit message prefixes, keywords, file paths) defined in the configuration.
- LLM-Powered Summarization: Generates concise, bulleted summaries of significant changes by analyzing commit messages.
- Markdown Output: Formats the summaries and commit lists into a well-structured Markdown section.
- Incremental Updates: Reads the existing changelog file (e.g.,
CHANGELOG.md) and automatically prepends the newly generated section, maintaining a running history. - Historical Generation: Generate changelogs for specific date ranges using
--from-dateand--to-dateflags. Perfect for backfilling weekly or monthly changelog entries for repositories with extensive history.
How it Works:
- Configuration: Uses a
.changelog_config.yamlfile (checked into your repo) to define filtering rules, the output changelog file path, and optionally customize LLM prompts. Aninitcommand helps generate this file. - Execution: Run the
generatecommand from within your repository. It uses the Git CLI and interacts with a configured LLM to produce the summaries. - State Management: Stores the hash of the last processed commit within a comment or metadata block inside the
CHANGELOG.mdfile. This ensures the tool only includes new changes in subsequent runs without requiring a separate state file.
What Gets Summarized
Important: The tool analyzes commit messages only, not code diffs or file changes.
For each commit since the last run, the tool extracts:
- Commit hash (full and short)
- Author name
- Commit date
- Commit subject (the first line of the commit message)
LLM Context
The LLM receives filtered commit messages in this format:
- abc1234 Add user authentication (John Doe, 2025-11-05 14:30)
- def5678 Fix login redirect bug (Jane Smith, 2025-11-04 10:15)
- ghi9012 Update password validation (John Doe, 2025-11-03 09:45)
The LLM does not see:
- Actual code changes or diffs
- File paths or file lists
- Commit bodies (only the subject line)
This design keeps API costs low and focuses on what developers already wrote in their commit messages.
How LLM Summarization Works
-
Filter commits based on rules in
.changelog_config.yaml:- Ignore commits with certain prefixes (
chore:,docs:,test:, etc.) - Ignore commits with certain keywords (
typo,cleanup, etc.)
- Ignore commits with certain prefixes (
-
Send filtered commits to LLM with:
- List of commit messages (hash, subject, author, date)
- Custom prompt from config (e.g., "Summarize in 2-4 bullet points")
-
LLM generates a concise summary focusing on features, fixes, and breaking changes
Output Format
The final changelog entry includes:
- Summary - LLM-generated bullet points highlighting significant changes
- All commits (collapsible) - Full commit list for reference
Example:
## [2025-11-05]
### Summary
- Added OAuth2 authentication support with Google and GitHub providers
- Implemented password reset functionality via email
- Fixed session timeout bug causing unexpected logouts
### Changes (5 commits)
<details>
<summary>All commits</summary>
- abc1234 Add OAuth2 authentication (John Doe, 2025-11-05 14:30)
- def5678 Implement password reset (Jane Smith, 2025-11-04 10:15)
- ghi9012 Fix session timeout bug (John Doe, 2025-11-03 09:45)
...
</details>
Goal:
To save developer time and improve project visibility by automating the creation of consistent, informative, and easy-to-read changelogs.
Metadata
Release files for automated-changelog 0.3.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| automated_changelog-0.3.0.tar.gz | 26.3 kB | Without provenance | Details for automated_changelog-0.3.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| automated_changelog-0.3.0-py3-none-any.whl | Python 3 | none | any | Details for automated_changelog-0.3.0-py3-none-any.whl |
Total release size: 45.1 kB
Release files / automated_changelog-0.3.0.tar.gz
| Download URL | automated_changelog-0.3.0.tar.gz |
|---|---|
| Size | 26.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
889e09b02f56f725ef848558853c293422f54a70dce95d0da94eab37432f349b
|
|
BLAKE2b-256 checksum How to use checksums |
b5f33bf61cdb737235d789944df1e84a77830fe034179ba6475426b59b4a3ff5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.12.4
|
Release files / automated_changelog-0.3.0-py3-none-any.whl
| Download URL | automated_changelog-0.3.0-py3-none-any.whl |
|---|---|
| Size | 18.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
6e84298e07f1eda72205d6a285150a3057fdfa1583d033e261bcb2b5cf4fcb7a
|
|
BLAKE2b-256 checksum How to use checksums |
72319af45489ca1bedf39eb867293cd9dfa542a58f984ac658928b1b0894db1a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.12.4
|
Security for automated-changelog 0.3.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.