The terminal install steps were hiding in a collapsed fold, so most people installing the app, who live in a terminal, never saw them. Now both gh checks sit open on the page. Should've been that way from…
Rebuilt the PR screens: four dropdowns and a checkbox used to hide rows unpredictably. Now: three tabs, plain-language verdicts, one publish button that matches what you picked. No more scrolling past…
Discord copy vanished from a batch once: no error, no note, just a post that never showed up because the account lived in a different set than the batch. Now the batch page shows a plan before you…
♥ 0⇄ 1↩ 0Open
Killed the Monday roundup—calendar-week grouping nobody asked for and couldn't opt out of. Now I pick which PRs go together, name the batch, and generate on demand. Held PRs sit in a list that turns red…
Your customers don't know what you shipped.
Merge & Tell reads every pull request your team merges and writes the update for the ones your customers should hear about: the changelog entry, the newsletter, the posts.
Before
After
Connect GitHub once and it just works. Merge & Tell is on the firehose from then on, so every pull request you and your coding agents merge flows in as it lands. You decide which updates wait for you and which go out on their own.
Free for one repo: 10 merged PRs and 25 drafts a month. No card, no expiry.
The point
A year of it, in one picture.
Every square is a day. It goes blue when something you built reached an audience, and it stays empty when nothing did. The left of this grid is what shipping in silence looks like. The right is what a merge that publishes itself looks like a few months later.
Example: a year of publishing on autopilot
Example data, not a real account
Why
Shipping isn’t telling.
Engineering ships every week. Customers hear about it every quarter, if the changelog gets written at all. In between they file tickets for features that already exist, sales can’t answer “what’s new since we last talked”, and the update email slips to next week again.
Every merged pull request is already a finished thing with a real diff behind it. The update is sitting right there, unwritten. Merge & Tell writes it, in your product’s voice, for the customer you name, so the people who pay for the product find out what changed while it still matters to them.
I built this because I was afraid of the telling part. Not the code. Shipping was fine. Saying “I made this” out loud was the bit I would skip, every time, and there is always a reason to skip it. Now I merge and the post is written before I can talk myself out of it. The only move I have left is to approve it.
How it works
Merge. Draft. Publish.
Your team merges a PR
Engineering ships the way it always does. Anyone connects GitHub once, and from then on Merge & Tell sees every pull request your team and its coding agents merge.
It drafts the update
Claude reads the diff and writes the changelog entry and the posts, sized for each channel and written for the customer you named.
It goes out
It posts to the accounts you connect. Nothing goes out until you say so, unless you set a network or the weekly digest to publish on its own, and the Autopilot bar shows how close you are to never pressing a button.
Features
Everything it does for you
It all does one job. The work you already did reaches the people you’re building for, in your voice. Each entry links to how it works.
Writes the post
A merge is the trigger. What comes out is copy about the lines that changed, aimed at someone specific, in a voice you chose.
- Drafts from the real diffA merge fires a webhook and Claude reads the changed lines. One pass for what shipped, one per channel for how to say it. Not your PR title reworded.
- Founder voice and company voiceOne merge can go out twice, in different words, once from the company account and once from yours. Copy written as a person never auto-publishes.
- Written for your buyerPoint it at your product site and it drafts the ideal-customer profile: who they are, what hurts, the words they use. Every draft is framed for them.
- Small PRs wait for a batch you buildA ten-line fix is not an announcement. Those merges wait until you group them into a batch and generate one update for the set.
Decides what counts
Most merges are not announcements. Which ones get through is a setting you write once, not a call you make every time.
- Noise never becomes a postBot authors, lockfile churn, paths you marked publish: never, and anything labelled marketing:skip are dropped before a token is spent.
- Split by who changes itThe repo owns its skip labels and per-path rules in a .marketing.yml. The app owns voice, ICP, hashtags and where it posts. A block in the PR body overrides both for that PR, but it can never make a post publish on its own.
- Hide a repo, completelyOne switch and a repo records nothing, publishes nothing, and stops appearing in every list and picker. Queued posts for it are cancelled.
Sends it
To your own accounts, at the size each network really allows, when you say so. One switch stops all of it.
- Every channel, sized to fitX, Bluesky, Mastodon, LinkedIn, Threads, Discord, Slack, WordPress, a newsletter and your own changelog. Reddit and Hacker News land in the same review queue as copy you paste yourself. Each one written to that network's real limit, counted the way that network counts it.
- Your accounts, not a middlemanConnect X, Bluesky, Mastodon, LinkedIn, Threads, WordPress, a Discord or Slack webhook, and your own Resend or Mailchimp. Merge & Tell posts as you; the tokens stay encrypted server-side and never reach the browser.
- Each repo posts where it shouldGroup connected accounts into named sets and point a repo at one. A set that has gone missing publishes nothing, never "everywhere" by accident.
- A queue with a stop buttonPublish now, at a time, or in the next free slot of your week. Retries back off, an attempt it cannot confirm is never re-sent, and one switch pauses the whole account.
- Post things that were not PRsThe composer writes an ad-hoc post through the same voices, sets, schedule and queue, with a live per-network preview before it goes.
Proves it worked
The part most tools skip. Where the clicks came from, a feed anyone can read, and an honest number for how much of the copy you kept.
- Links tagged for attributionOpt-in UTM tagging, applied per network as each post is queued, so your analytics can tell a Bluesky click from a LinkedIn one.
- Your own changelog feedThe same drafts render as a public HTML page with JSON-LD, plus Atom and JSON feeds, at your own URL.
- Proof it is worth itKept-rate: how much generated copy you publish, and how much you rewrote first. If the drafts are bad, the number says so.
Reads from GitHub · posts to the accounts you connect
- GitHub
- X
- Bluesky
- Mastodon
- Threads
- Discord
- Slack
- WordPress
- Newsletter
Receipts
It runs on itself.
Everything below was written by Merge & Tell from a merged pull request in this repository, and published to its own accounts. Live off each network’s public API, not a screenshot and not curated.