How to do it
- Send releases in Add the socialhandoff-announce-action GitHub Action to your repo, or point a signed webhook at SocialHandoff. Each published release arrives as a trigger event.
- Draft per network An agent reads the release body and drafts a thread for X and Bluesky, a single post for LinkedIn, and a Mastodon post that fits 500 characters.
- Apply brand memory Voice rules and product names from brand memory keep version numbers, feature names, and tone consistent across every release.
- Approve from the inbox The approval.requested webhook pings your team. A reviewer edits inline, approves, or rejects from desktop or the phone swipe stack.
- Publish with a citation The post goes out and the audit log records which GitHub release it came from, so anyone can trace a post back to the tag.
v2.4.0 is out. Scheduled exports now run on your own cron, CSV imports handle 10x larger files, and the API returns rate-limit headers on every response. Full notes and upgrade steps in the release. (Drafted from the GitHub release v2.4.0, approved by the maintainer on duty.)
How release announcements work in SocialHandoff
A release is the most reliable content source a software team has. It has a date, a version, a list of changes, and a link. That structure is exactly what an agent needs to write a good post, and exactly why a human still needs to check it: release notes often include internal ticket names, half-finished features behind flags, or breaking changes that need careful wording.
Setup in four steps
- Connect the networks you announce on. See connect X and connect LinkedIn.
- Add the GitHub Action to your release workflow. The GitHub releases guide shows the YAML, and the GitHub Actions integration covers secrets.
- Write brand memory: product name spelling, words you avoid, how you describe breaking changes. See brand memory.
- Decide who approves. Owners approve by default; on Pro you can require more than one reviewer.
Permissions to give the agent
Give the release agent a key with draft permission only, scoped to the networks you announce on. It does not need schedule or analytics access to write an announcement. If you later want tagged patch releases to go out on their own, promote the agent on one network through the trust ladder and keep major releases draft-only by policy.
Measuring results
Use per-post metrics where the network returns them to compare which release posts earned clicks and replies. Tag release links with UTM parameters using the UTM builder so your product analytics shows which announcements drove upgrades. Treat best-time suggestions as heuristics, not rules.
Pitfalls to avoid
- Announcing pre-releases by accident. Filter drafts or reject them in one tap; nothing ships without approval.
- Pasting raw changelogs. Ask the agent to lead with the user-facing change, not the commit list. The release notes template and changelog thread template give it a shape.
- Forgetting alt text on screenshots. The alt text guardrail blocks the post until it is added.