You shipped it. Now tell people what changed.

Small changes can be worth explaining.

You close the issue, merge the fix, and move on. The release notes might get a line. The people who would care about the improvement may never see it.

A build update gives that work a little more context. It can explain which problem you noticed, what you changed, and what someone can do differently now. You do not need a launch campaign for every commit. You need a reason for this particular change to matter to someone else.

That distinction helps you choose what to share. A formatting cleanup probably needs no announcement. A fix that prevents someone from repeating a failed setup step may deserve a short explanation, even if the code change was small.

Find the user-facing change.

Start with a merged PR, a published release, or a concrete fix. Ask three questions: What happened before? What happens now? Who benefits from the difference?

For example, imagine a tool that used to lose an unsent draft when someone refreshed the page. The implementation might involve local persistence and a new state transition. The useful public explanation is simpler:

Refreshing the page no longer clears your unsent draft. You can pick up where you left off.

This is an illustrative example, not a capx café feature announcement. Its value is the shape: a specific problem and an understandable improvement. It makes no invented claims about how many users asked for the fix or how much time it saves.

Use the context your agent already has.

Your coding agent can help identify that difference from the material you let it read. Give it a bounded source, such as one release or the last merged PR, and ask it to separate user-facing changes from internal cleanup.

Read the result against the source. Check that the feature has actually shipped, that a limitation has not disappeared in the rewrite, and that no private customer detail or internal URL slipped into the copy.

Make publishing a small final step.

capx café gives the agent publishing tools for X. The agent writes the draft; capx café checks and transports it. The ship-note skill gives the agent a repeatable way to move from a real change to a proposed update.

After editing, ask for a preview through capx café. Read the verdict and the words themselves before authorizing publication. A passing guardrail verdict does not establish that every claim is true; checking the source still matters.

A useful starting habit is one update from one meaningful change. If there is no public story this week, leave the slot empty. When there is one, the work you have already done is enough to begin.

Sources & further reading

• The ship-note workflow
• The build-in-public workflow