Blog posts as pull requests: review content like code

Blog posts written as pull requests. Your blog is a branch, publishing is a merge, and the diff is your editorial interface. Every word added or removed shows up in the same place you review features, and nothing ships until you merge it. This post is a pull request right now, waiting on the founder's merge.

Why you never actually blog

If you run a product from a repo, you know the pattern. You want a blog. Blogging is how you get found, it is the thing solo founders are told to do, and you have shipped plenty of code. Yet the blog stays empty.

The reason is not writer's block. It is that blogging alone means writing and editing and formatting and publishing and promoting, all in a loop with no one to hand anything back to you. An editor fixes your commas, tightens your argument, and catches the claim you cannot back up. Without one, every post is a solo sprint, and the sprint quietly never starts.

The fix is not better writing tools. It is a workflow that gives one person an editor's review. That is what pull requests do for code, and it works for prose.

What the loop looks like

The agent drafts on a branch, opens a pull request, you review the diff, you merge, and the deploy runs. That is the whole loop, and it is the approval model you already trust:

• The draft lands as a branch, not a scratch file in your notes app.
• The changes come to you as a pull request, not an email.
• You review the diff instead of re-reading a whole draft.
• You merge when it is right. Nothing goes out without that merge.

The approval gate is the tool you already use every day. You are not learning a new review screen; you are reviewing like you review features. Nothing publishes without your yes, and your yes is a merge you already know how to make.

What you actually review in a blog PR

A blog PR is not a wall of prose. It is a set of things you can check the same way you check a code change:

• Frontmatter and metadata. Title, meta description, slug, date, tags. These are the first lines of the file, and they are wrong most often.
• Claims you cannot defend. Read each added sentence as a unit. Would you assert it in public? If a stat has no source, that sentence is a bug.
• Every link. Outbound links can rot or point at the wrong thing. Internal links should match existing paths. Check both.
• The diff as a whole. Added lines are new prose, removed lines are edits. Look at what changed, not at what stayed the same.

Read the diff, not the document. That is the entire trick.

What the stack costs you

Nothing you do not already have:

• Markdown files in the repo. One file per post.
• A build step. Your static site generator already does this.
• A post route and a listing page.
• A sitemap entry.

That is all it takes. No CMS, no database, no separate editor tool. Text lives in git like everything else, and it deploys through the same pipeline as your code.

Where it breaks, honestly

PR-based blogging is not for everyone, and pretending otherwise convinces no one:

• Images and binary assets. Keep them out of the prose diff. Store images separately and reference them from the post; keep only text in git.
• Teammates who do not live in git. A content writer who has never opened a terminal will not adopt a PR workflow. This is for founders who already ship code, not for grafting a marketing team onto git.
• Drafts that live outside the repo. If your ideas start in a notes app, they have to migrate to a file before they become a branch. That step is friction, and it is real.

Each of these is a workflow decision, not a reason the approach fails. Text in git, assets on the side, and begin where the contributor already feels at home.

The part nobody else has: approve once, it stops asking

The deeper difference is memory. Review the same class of post twice, and the third one stops asking. Tell Marlo it can decide this kind of thing on its own from now on, and it will. Standing permissions mean fewer questions over time, not full auto.

This is what separates the loop from "email me forty drafts a day." A tool that asks about everything teaches you to approve blindly. A tool that learns the calls you have already made lets the approval stay where it matters and sends the rest straight to your review.

Review a blog PR like the code change it is. Marlo runs a daily standup across a team of marketing agents, drafts on a branch, and opens the PR. You approve from Slack or the dashboard, which is step three of how the loop runs.

This post is a pull request right now

We dogfood the thing. The page you are reading ships from this repo, and the agent that audits the site is the same one that drafts your posts.

If you want your marketing loop to look like your dev loop, start free and read the first PR that shows up in your inbox.