Release Tweets

Use when the user asks for a release tweet, launch tweet, X announcement, release thread, changelog-to-tweet rewrite, or social copy for a shipped version. This skill is about release copy, not cutting the release.

Ground The Copy

• Verify the release target before writing confident copy:
  • read the relevant CHANGELOG.md section or GitHub release notes
  • check the tag/release/npm/appcast/artifact state that applies to the project
  • distinguish Unreleased, beta/prerelease, stable, hotfix, and correction releases
• Do not say a feature shipped only because it is in the top changelog block. Confirm the tag/release/package evidence when available.
• Lead with user-visible wins: features, integrations, workflow improvements, install/update reliability, security fixes.
• Avoid leading with CI, coverage, validation, refactors, internal migrations, or release mechanics unless that is the actual story.
• If evidence is incomplete, say what is unverified and draft with softer wording.

Launch Tweet Shape

• One standard tweet under 280 characters, with room for one URL.
• Typical format:
  • product + version
  • blank line
  • 3-4 compact emoji-led feature bullets
  • blank line
  • one short punchline
  • release/changelog URL
• Use emoji bullets by default for launch tweets. Pick clear, low-noise emoji that match the feature or product; skip only when the user asks for plain text or the release is incident-style.
• Tone: high-signal, compact, confident, a little dry when earned. Not corporate.
• One joke max. Let the feature bullets do the work.
• Put the release/changelog URL at the end.
• Count final raw characters before presenting it as ready to post.

Beta, Hotfix, Correction