Draft weekly release notes
Connect the release record
Section titled “Connect the release record”Connect GitHub, the production deployment system, and the issue tracker. Add product plans or customer notes as synced sources only when they explain the member problem behind a shipped change.
Run the report once. Confirm that the deployment record, not merge time, decides what shipped.
Create the scheduled task
Section titled “Create the scheduled task”Every Thursday at 2:00 PM Pacific time, draft release notes for production changes since the previous successful run. Start from deployment records, then trace each deployed head to its merged pull request and issue. Include only member-visible behavior. For each item, state what changed, who it affects, and what the member can do now. Link the deployment and pull request. Exclude internal refactors, tests, operational repairs with no member effect, and merged work that is not deployed. Return the draft in this conversation. Do not post a result if no member-visible change shipped. Do not edit or publish the changelog.
The next run starts after the last successful result. A failed run does not skip a release.
Publish after review
Section titled “Publish after review”Review the draft, then ask for a pull request:
Prepare a pull request with the approved changelog items. Keep their wording, order, dates, and links. Build the docs and check every internal link. Do not merge it.
Use Tasks, then Scheduled to pause the task or change its schedule. Use Runs to check the sources for an earlier draft.