A diff explains which files changed. It rarely explains why someone should stop and look at the result.
Giving an agent a changelog and asking for a post tends to produce a feature list with adjectives. It can be accurate and still fail to show anything interesting.
I am trying a different starting point: the change someone can actually see. What was there, what I changed and which difference is worth demonstrating.
The before-and-after piece
I have added a before-and-after story template for this kind of content. It takes two visual states and a transition between them. The composition is defined in code, so an agent can help build a piece without redesigning its entire structure each time.
There is an important caveat: two states drawn to explain an idea are not automatically two screenshots of a product.
If I prepare an illustrated demo, I describe it that way. If I claim to show a change to a real website, I need captures of both versions under comparable conditions.
That distinction may not sound very promotional. I find it practical: it keeps an edit from promising an improvement that only exists inside the video.
Pick something smaller than a release
A release might contain twenty changes. A short piece does not have to explain all of them.
For a component library, an awkward interaction becoming clearer may be more useful material than a screen full of feature names. For a website, it could be navigation that preserves state. Those are possible angles to verify in a project, not results I am attributing to a specific release.
I would ask the agent to find candidates in the diff and check them against the code. Before writing copy, I want to know what we can demonstrate and what would remain an unsupported claim.
A brief that separates facts from proposals
This is an example task, not a command that publishes anything:
Review the change and propose a before/after piece.
Deliver:
- the problem it addresses, with a source;
- the states we should capture;
- the conditions needed for comparison;
- a short draft describing only what is demonstrated.
Flag a missing previous version.
Do not fabricate a capture or publish the result.The answer might be “there is not enough visual difference.” That is useful too. Some improvements are better explained with code or a longer article.
Keep the comparison fair
I would try to use the same viewport, data and action. If the content, zoom level and timing all change, it becomes difficult to tell what the actual improvement contributed.
The template also includes presentation choices: text entrances, framing and elements shared across scenes. An agent can apply those choices. They should not change the evidence being shown.
If the “before” feels slower because I inserted an artificial pause, the edit is telling a different story. Good pacing is not a reason to manufacture the problem.
Write the copy afterwards
Once the comparison makes sense, the writing gets simpler. I can explain what was awkward, which decision I made and what remains unresolved.
Not every piece needs a closing question. Not every adjustment deserves to become a major announcement. Sometimes an interaction and two useful sentences are enough.
I also have no measurements showing that this format produces more sales or reach. I am using it to explain changes with less filler, not presenting it as a social-performance guarantee.
The template is ready to work with. Choosing a worthwhile example and checking the comparison are still part of producing each individual piece.