The Generation Process
When you trigger a changelog generation, either through the webhook API or by clicking "Fetch Updates" in the dashboard, AutoChangelog goes through a multi-step process to create your entry. Understanding this process helps you get the best results from the AutoChangelog platform.
Step 1: Triggering Generation
Generation starts when you call the webhook from your deployment pipeline or manually click "Fetch Updates" in your dashboard. AutoChangelog receives the request, validates your authentication, and creates an entry record. A background job is then queued to fetch your data from GitHub and generate the content.
Step 2: Fetching Data from GitHub
AutoChangelog uses the GitHub App you installed to fetch data about what changed since your last changelog entry. We track the SHA of the last commit we documented, so we know exactly where to start. We fetch all commits since that point, look up any pull requests that were merged, and get a summary of which files changed.
For each commit, we read the commit message. For pull requests, we read the title and description, which often contain more context than individual commits. For file changes, we look at filenames, additions, and deletions to understand the scope of changes. We don't store your source code, just use it to provide context to the AI.
Step 3: AI Processing
The fetched data is sent to our AI with specific instructions to write like a professional product team. The AI is told to focus on what users can now do, not technical implementation details. It groups related changes together, explains why changes matter, and filters out internal changes that don't affect users.
The AI is trained to be factual and only mention changes that appear in the data. It never invents features. It writes in a warm but measured tone, avoiding excessive exclamation marks or marketing speak. It uses natural section headings that fit the content rather than rigid templates.
Step 4: Entry Creation
The AI returns a structured response with a title, tags, summary, and body content. AutoChangelog parses this response and saves it as a changelog entry. The entry includes the version number (either from your webhook request or auto-incremented), and the last commit SHA is saved so we know where to start next time.
Depending on your auto-publish setting, entries are either published immediately or saved as drafts for you to review first.
What Gets Included
The AI focuses on changes that matter to your users. New features and capabilities are highlighted, explaining what users can now do that they couldn't before. Improvements to existing functionality are described in terms of the benefit to users. Bug fixes are mentioned when they resolve issues users might have encountered. Breaking changes are called out prominently so users know if they need to take action.
What Gets Filtered Out
The AI automatically skips changes that don't affect end users. Internal refactoring that doesn't change behavior is omitted. Test file changes, CI/CD configuration updates, and dependency updates are filtered out unless they add user-facing features. Documentation-only changes, environment variables, and config files are also excluded. The goal is a changelog that's useful to your customers, not a commit log.
Editing and Regenerating
The AI-generated content is a starting point, not the final word. You can edit everything using the rich text editor: the title, summary, body, tags, and version number. Add images, links, or additional context. Remove sections that aren't relevant. The entry is yours to shape.
If you're not happy with the generated content, click "Regenerate" to get a fresh version. You can also add custom notes and instructions when regenerating to guide the output, like asking it to focus on a specific feature or use a particular tone. The AI may emphasize different aspects or phrase things differently each time, so regenerating can help if the first attempt missed something important.
Version Numbers
Version numbers are determined in order of precedence. If you specify a version in your webhook request, that exact version is used. If you specify a bump type (patch, minor, major), we increment from your last entry's version. If you don't specify anything, we default to a patch bump.
You can always manually edit the version number in the entry editor before publishing, regardless of how it was initially determined.
Processing Time
Most entries are generated within 30 to 60 seconds. Larger deployments with many commits may take a bit longer as there's more data to analyze. If generation fails due to API issues, we retry automatically.