Stack
The chore I refused to keep doing
Every time I shipped a release, I would copy the changelog, reformat it for each platform, swap the tone, and post it by hand in five places. It took twenty minutes, I did it inconsistently, and I usually skipped a channel or two out of laziness. s2p ("ship to posts") was me deciding that a computer should do this, every time, the same way.
How the pipeline works
The trigger is a published GitHub release. A workflow picks up the release notes, an LLM rewrites them into the right voice and length for each channel, and the result is queued for posting. The whole thing is a chain of small, boring steps, which is exactly what makes it reliable.
- A GitHub webhook fires when I publish a release.
- The release notes are reformatted per channel: short and punchy for one, longer and technical for another.
- Each post is generated from the same source of truth, so the channels never drift apart.
The lesson hiding in the boring parts
The interesting part was not the LLM rewriting text, it was the plumbing. Reliable automation is mostly about handling the unglamorous edge cases: what happens if a channel is down, if the release has no notes, if a post fails halfway. I learned to make every step idempotent and to log loudly, so a half-finished run never silently posts the same thing twice or drops a channel without telling me. The AI part was the easy 20 percent. The trustworthy plumbing was the 80 percent that made it something I actually rely on.
Lessons learned
- Automate the chores you keep skipping. Consistency is the real win, not the time saved.
- One source of truth (the release notes) keeps every downstream channel in sync automatically.
- The LLM step is the easy part. Reliable triggers, retries and idempotency are where automation succeeds or fails.
- Log loudly. An automation you cannot observe is one you will stop trusting the first time it misbehaves.