Ship-to-Story Content Drafts

Ship-to-Story Content Drafts is a routine your Townie AI assistant runs weekly, or when notable work merges: it reads merged pull requests, closed tickets, and changelog entries, picks the handful customers would care about, and drafts each as a plain-English changelog note, social post, or blog blurb. Every draft links back to the source PR or ticket so you can verify before publishing.

To: your Townie

Subject: Create me a Ship-to-Story Content Drafts routine

Build me a routine that turns what engineering just shipped into content I can actually publish, so our launches and improvements don't go unmarketed.

Run it on a schedule (e.g. weekly), or when notable work merges.

When it runs:
- Scan what shipped — merged pull requests, closed feature tickets, changelog entries — and pick out the handful that customers would actually care about.
- For each, draft a short, plain-English take: what changed, who it helps, and why it matters — as a changelog note, a social post, or a short blog blurb.
- Skip internal refactors and noise; translate engineer-speak into customer benefit.

Details that matter to me:
- Lead with customer value, not implementation detail.
- Match our voice and give me a couple of format options (post vs. changelog) per item.
- Link back to the ticket/PR so I can verify before publishing.

Output: a set of drafted, ready-to-edit content pieces delivered to me.

My default: draft everything for me to review — don't publish anything on its own.

Before you build this, tailor it to the integrations I actually use and what you already know about me. Don't take the above at face value — ask me the critical questions that make it stronger: which tools and integrations to use, what the output should look like, and how much autonomy you should have (what to do on your own vs. check with me first).

Sent when you sign up — works as-is, or edit anything.

Get started with this routine

Everything stays a draft — nothing publishes itself.

See it work: last week's ships, ready to publish

Turn what we shipped into content worth publishing

Engineer-speak in, customer benefit out.

How this routine works

Works with

It runs weekly, or when something notable merges
Your Townie watches the stream of shipped work so you don't have to sit in the engineering channels to know what happened.
It reads like an engineer, picks like a marketer
Merged PRs, closed feature tickets, and changelog entries — filtered down to the handful customers would actually care about. Internal refactors and noise never make the cut.
You get drafts in your voice, with receipts
Each ship arrives as a plain-English draft in a couple of formats — changelog note, social post, blog blurb — linked back to the PR or ticket so you can verify before you publish.

Ship-to-Story Content Drafts FAQ

It's a routine your Townie AI assistant runs weekly (or when notable work merges): it scans merged pull requests, closed tickets, and changelog entries, picks out what customers would actually care about, and drafts each item as a changelog note, social post, or short blog blurb — customer benefit first, engineer-speak translated out. You build it by sending the message on this page.

No — everything it produces is a draft for your review; publishing is always yours. Its access to your repos and trackers is read-only through the accounts you connect. Read more in our security overview.

Wherever shipped work is visible — your code host (like GitHub) and your issue tracker (like Linear) — plus email for delivering the drafts. If your team keeps a changelog doc, it can read that too.

It leads with visible benefit: anything a customer would notice, ask about, or be unblocked by makes the cut; refactors, dependency bumps, and internal tooling don't. Tell it about your audience once and the filter sharpens.