---
title: "How to Auto-Draft a Changelog from Merged Pull Requests"
summary: "Generate a changelog draft whenever a pull request merges, with the customer requests it fixes attached. Rules by base branch and PR label, and why a human still publishes."
date: 2026-11-13
author: "FeatureOS"
canonical: https://featureos.com/blog/auto-draft-changelog-from-pull-requests
markdown: https://featureos.com/blog/auto-draft-changelog-from-pull-requests.md
lastUpdated: 2026-11-13
categories: ["release-notes","guides"]
readingTime: 1
---

To auto-draft a changelog from merged pull requests, set a rule that watches a branch (usually `main`) and, if you want, a PR label. When a matching PR merges, your changelog tool creates a draft entry. In FeatureOS the draft also carries the feedback posts linked to that PR, and it is never published automatically: you edit the wording and publish.

## Why draft from PRs but not publish from them?

PR titles are written for developers ("fix: debounce search input"). Customers need "Search no longer lags while you type". A generator can collect what merged, but a person should decide what is worth announcing and how to say it. Drafting removes the blank page; reviewing keeps the voice. For open-source generators that work from commits and tags, see [GitHub changelog tools compared](/blog/github-changelog-tools). For writing the entry itself, see [how to write release notes](/blog/how-to-write-release-notes).

## What a changelog rule contains

- **Base branch.** Only PRs merged into this branch count, for example `main` or `release`.
- **PR label (optional).** Only PRs with this label count, for example `user-facing`. This filters out refactors and dependency bumps.

When a PR matches, FeatureOS creates a draft changelog and attaches the posts linked to the PR, so the entry already points at the requests it answers.

## Set it up

1. Connect GitHub in **Organization Settings > Integrations > GitHub** ([details](/integrations/github)) and accept the updated GitHub permission.
2. [Link PRs to feedback posts](/blog/link-github-pull-requests-to-customer-feedback), manually or with the post URL in the PR description.
3. Add a changelog rule with your base branch and optional label.
4. Label user-facing PRs. Merge as usual.
5. Open the draft, rewrite the headline in plain language, and publish.

## Tips

- Use one label for "customers should hear about this". It is the cheapest filter.
- Skip the rule on branches that merge dozens of PRs a day unless you filter by label.
- Publishing notifies the voters on the attached posts, which is the point.

Availability note: this needs an updated GitHub permission (pull requests, read-only). An admin accepts it once in GitHub; existing issue linking is unaffected.