Weekly Changelog Agent

Changelogs get written the week somebody has time, which is never the week things shipped. Every Friday afternoon this agent reads the pull requests merged since Monday and writes the week in plain language: what shipped, what got fixed, what breaks, and who did it. It holds up because it describes each change from the pull request itself and lists anything it cannot describe rather than filling the gap with a guess.

What people use it for

• Tell support what shipped - Support finds out about a change from a confused customer more often than from engineering. One Friday message in plain language means they read it before Monday's tickets arrive.
• Surface undocumented breaking changes - Anything that removes or renames something lands in BREAKING with the migration note quoted, or with a line saying the author never wrote one. That question gets asked while the author is still around.
• Stop writing release notes by hand - The raw material is already in your pull request titles and bodies. This turns that into a written changelog every week without anyone opening the compare view on a Friday evening.
• Give the company a Friday read - Non engineers get one message they can actually follow, with authors credited by handle. It is the cheapest way to make a quiet infrastructure week visible to the people funding it.

Before you fork

What does it need connected?

A GitHub credential with read access to the repositories you want covered, and one Slack channel to post in. During setup you name the repos, the audience, and the style you want. It only reads from GitHub and never comments, tags, publishes a release, or pushes anything.

What does it cost to run?

One run a week per workflow, whether your team merged four pull requests or forty. The run reads the week's merges and posts a single message, so cost tracks the schedule rather than your repo size. Teams that ship daily sometimes move it to twice a week, which doubles it.

What if it describes a change wrongly?

It writes only from the pull request title, body and linked issue, so a wrong line usually means a pull request described itself badly, which is worth knowing. A merge with no usable description goes into INTERNAL marked description unclear instead of being narrated. You can rehearse it on the staged weeks before pointing it at your real repos.