How to turn a pull request into a post on X (with examples)
By Naod Tadele · · 5 min read
A merged pull request is one of the best sources of posts you have. It has a clear scope, a reason it exists, and usually a short story in the description and review comments. Most of the work of writing the post is already done.
The problem is that a PR is written for reviewers. It assumes they know the codebase, the ticket and the edge cases. A post on X is read by people who know none of that. The job is translation, not invention.
Why a PR works better than a pile of commits
Commits are often small and noisy: "fix test", "wip", "address review". A pull request groups them into one change with one purpose. That makes it closer to the shape of a good post already.
A PR also tends to contain things commits don't:
- The why. A good description says what problem the change solves.
- The trade-off. Review threads show what you considered and rejected.
- The before and after. Screenshots, timings or examples of old and new behavior.
If you want to work from commits instead, the guide on turning GitHub commits into posts covers grouping them into one story.
Step 1: Pick a PR worth posting
Not every PR deserves a post. Dependency bumps and refactors with no visible effect usually don't. Look for a PR that:
- Changes something a user can see or feel
- Fixes a bug someone actually reported
- Involved a real decision between two approaches
- Taught you something you didn't know before you started
One good PR a week is plenty to post about.
Step 2: Find the one sentence that matters
Read the description and ask: if I could only say one thing about this change, what would it be? It's usually the user problem, not the implementation.
Reviewer version:
Refactor alert ingestion to dedupe on deploy_id before fanout. Adds index on incidents(deploy_id). Closes #412.
Post version starts from the problem:
One bad deploy used to page on-call engineers six times. Nightshift now groups every alert from the same deploy into one incident.
Same PR. The second version is about the person who gets paged at 3am.
Step 3: Add one concrete detail
A post without a detail reads like marketing. Pull one specific thing from the PR: a number from your own tests, a screenshot, a line from the review, an example input and output.
Tested it against last week's worst night: 40 alerts became 1 incident with the full timeline attached.
Only use numbers you actually measured. If the PR has no number, use an example instead. Developers notice when figures look rounded up.
Step 4: Decide if the decision is the story
Some PRs are more interesting for what you chose than for what you built. If the review thread has a real debate, that can be the post.
We almost grouped Nightshift alerts by time window. Simpler, but two unrelated outages at once would merge into one incident. Grouping by deploy is stricter and much easier to explain to users. Went with that.
Posts like this get replies from other engineers, because they can disagree with you. That's a good thing.
Step 5: Cut the internal words
Before you post, remove anything only your team understands:
- Ticket numbers and branch names
- Internal service names
- Function, table and column names (unless the audience is other developers and the name helps)
- Words like "refactor" or "fanout" when "rewrote" or "sends to" will do
Then read it as someone who has never seen your product. Does it still make sense?
Three post shapes that fit most PRs
- Problem and fix. What hurt, what you changed, what's better now. Works for bug fixes and small features.
- Before and after. Two screenshots or two short descriptions side by side. Works for UI changes and performance work.
- The decision. Option A, option B, what you picked and why. Works for architecture changes and anything with a long review thread.
A before and after example:
Before: Nightshift showed incidents as a flat list sorted by time. After: incidents are grouped by the deploy that caused them, with the commit right at the top. The first question on-call asks is "what changed?" Now it's the first thing they see.
Should you link the PR?
If your repo is public and the PR is a good read, linking it can be great for other developers. For most product posts, keep the link out of the main post. Put it in a reply if people ask how it works. The post should stand on its own.
A quick template
[The problem, in the user's words] [What you changed, in one sentence] [One real detail: a number you measured, a screenshot or an example]
Fill it in, cut every internal word, and you have a post.
How Loudcode helps
Loudcode reads your GitHub commits, pull requests and releases, so the PR description and the story behind it are already there when it drafts. It writes in your Voice & tone settings and adds a screenshot of your live app on visual posts. You can also say "post about what we just shipped" from Claude Code, Cursor or another editor through the MCP server right after you merge. Every draft waits for your approval before it goes to X.