Newsletter drafting

Each week the automation reviews what merged in GitHub, picks the changes that matter to customers, and drafts a newsletter in Mailchimp that explains them in plain terms, ready for you to review, polish, and send.

Instead of staring at a blank campaign, you start from the week's real highlights, so sending is an edit rather than a project.

Scoped access

• GitHub, read merged changes
• Mailchimp, draft campaigns only

How it fails silently

Newsletter drafting fails silently when merged does not mean live. A pull request landed this week, so the automation writes it up as a shiny new feature, but it shipped behind a flag that is still off, or it was reverted two commits later, or it is staged for a release that has not happened. The draft reads like a confident announcement. Sent unattended, it tells every customer to try something that is not there. The run looks like a productive week summarized well. The result is a list full of people clicking through to a feature that does not exist yet.

What the overseer catches

Once the edition is drafted, the overseer checks each highlighted change against whether it actually shipped. A feature still behind an off flag, a change reverted a few commits later, work merged but not yet released, is what it catches, flagging that item for you so you never invite customers to something they cannot find.

The draft itself always comes to you, so you decide what ships and how it reads. The automation does the assembly, not the sending.

On top of that, anything the draft highlights that is not genuinely live gets flagged, so your review is not only about wording but about not announcing something the product has not actually shipped.