How to do it
- Collect the week Entries arrive through a signed webhook from your changelog tool or from an automation in n8n or Zapier that runs every Friday.
- Group and rank The agent groups entries by theme and leads with the change that affects the most users, using plan_week to place posts across the next few days.
- Draft per network X and Bluesky get a numbered thread, LinkedIn gets one post with a short list, Mastodon gets a compact summary under its character limit.
- Review in one pass Approve the thread, edit a line inline, or reject a single post without touching the rest of the week.
Shipped this week (1/4) The small stuff that adds up: faster search, fewer clicks, and a fix for that Safari date picker. Thread below. (2/4) Search now returns results as you type, including archived projects.
Why changelog posts need a different workflow
A release announcement is one big moment. A changelog is a steady drip. The workflow that suits a changelog is batching: collect a week of entries, pick the two or three that matter to customers, and write them up once. An agent is good at the batching and the first draft. A person is still better at knowing which fix a key customer has been waiting for.
Setting it up
- Connect X and Bluesky first, since threads suit changelogs best. See connect Bluesky.
- Send entries in with a webhook from your changelog tool, or schedule a weekly run in n8n or Zapier that posts the week's entries to the REST API.
- Give the agent the changelog thread template as a reference and the feature announcement template for the lead item.
Agent permissions
A changelog agent needs draft and schedule so it can spread posts across the week. It does not need analytics. Keep it on the networks where you actually post changelogs; a key scoped to X and Bluesky cannot draft a LinkedIn post by mistake. Details are in agent keys and permissions.
Measuring what works
Compare engagement on threads that lead with a fix against threads that lead with a new capability. Per-post metrics show the difference where the network reports them. Use the thread splitter to test how a long list breaks across posts before you approve.
Pitfalls
- Listing everything. Ten entries in a thread read like a commit log. Ask for the top three and a link to the full changelog.
- Internal names. Put codenames in brand memory as banned terms so they never reach a draft.
- Duplicate posts. If a big item also got its own release announcement, reject it from the weekly thread. Duplicate protection catches identical text, not the same idea reworded.