BUILD auto+gate changelog-to-content
Every product update becomes a post worth reading
The file
take it and run it.
One markdown file: the goal prompt, the verifier prompt, and the stopping condition. Read it before you run it. MIT licensed, no account, nothing to sign up for.
curl -fsSL https://vibemarketers.ai/loops/changelog-to-content.md -o .claude/loops/changelog-to-content.mdThe loop
copy it.
Engineering ships every week. Marketing finds out at the retro, if at all. This loop reads what actually shipped and drafts the posts, so the gap between merging something and telling anyone closes to a day.
Use it when your changelog is real but your blog is empty, or when the person who would write these posts is not in the standup where the work gets described.
You need read access to your commit log or release notes. Nothing else.
You get one draft per buyer-visible change, each naming the commit it came from, and a discard list so you can check what it chose to skip.
The gate is you. It drafts and opens a PR. It never publishes and never sends.
Goal prompt
Read every commit or release note for <project> since <date>. Discard
anything with no buyer-visible change: refactors, lint, dependency bumps,
internal renames. For each remaining change, draft one post that names what
changed, who it is for, and what they can now do that they could not before.
Open a PR. Never publish without the gate.Verifier prompt
Read every draft against the commit it came from. FAIL if any post describes
a change with no commit behind it, if any post is written for an engineer
rather than a buyer, if any number has no source, or if anything published
without a PR approval. Otherwise PASS.Stopping condition
Every buyer-visible change since the last run has exactly one draft naming its commit, one PR is open, and the verifier marks PASS.
MCPs it needs
- GitHub (read the commit log)
Want everything at once
The installer writes the three starter skills and every
published loop into .claude/. Read the
script first.
curl -fsSL https://vibemarketers.ai/install.sh | bashThe receipt
- Baseline
- 15 commits since 2026-09-17 and no process for turning any of them into something a reader would see. Every shipped change was invisible outside the repo.
- Hypothesis
- Filtering commits by whether a user of the site would notice the change separates publishable work from internal churn without a human reading all 15.
- Intervention
- Read 15 commit subjects since 2026-09-17. Classified each as buyer-visible or internal churn, then kept only the visible ones as draft angles.
- Result
- 15 commits read, 10 buyer-visible, 5 discarded as internal churn. The 10 include the file downloads, the skills page and the catalog rework. No post was published: this run drafts angles, and the gate is a human.
- Commercial signal
- none
- Attribution limits
- A commit subject is a weak signal of buyer impact. A one word subject can hide a large change and a verbose one can hide nothing. This classifies subjects, not diffs.
- Learning
- Two thirds of commits were buyer-visible, which is higher than expected and suggests the filter is too loose rather than that the work was unusually user-facing. It should read the diff, not the subject.
- Next intervention
- Classify on the diff rather than the commit subject, and test whether the same 15 commits produce a smaller, better list.
Sources: changelog run output, lab/changelog, collected , window: 15 commits since 2026-09-17, single run .
One entry per run, append-only, newest first. Corrections append a dated line.
Inside a company
where the lane changes.
VibeMarketers tests the loop. SuperMarketers runs it on a real team.
- Problem
- The team ships constantly and nobody outside the team ever hears about it.
- Source of truth
- The commit log or the release notes, and the Brain for who the buyer is.
- Permitted actions
- Read commits, draft posts, open a PR. Never publish, never send.
- Required approvals
- Product marketing approves each draft before publish.
- Owner
- Product marketing lead
- Metric
- Share of buyer-visible releases that got a post, and time from merge to draft.
On a real team this reads the release notes rather than raw commits, because commit subjects are written for reviewers and release notes are already one translation closer to the buyer.
Running this on your own site is one person reading a diff. Running it inside a company changes four things, and the guide covers them. When it stops being a file you copy and becomes a build, SuperMarketers does the same loop model inside your stack, on your keys.