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

• Beta/prerelease:
  • make beta status explicit
  • avoid implying stable promotion
  • phrase as "beta N", VERSION-beta.N, or "preview" as appropriate
• Hotfix/correction:
  • be direct and accountable
  • state what slipped, what is fixed, and the new version
  • skip jokes unless the user asks for a lighter tone

Threads

• First agree on the generic launch tweet.
• Then write follow-ups one at a time. When the user says next, provide only the next reply.
• Each follow-up should focus on one feature or user workflow.
• Include a docs/release URL for the specific feature when available.
• Avoid repeating the version in every reply when the thread context already has it.
• Good follow-up length: 160-220 raw characters. Hard cap: 280.

Posting And Clipboard

• Draft by default. Do not post to X/Twitter unless the user explicitly asks.
• If asked to copy, use pbcopy on macOS and report that it is copied.
• If asked to post from Peter's setup, prefer the local bird/xurl workflow if available, then verify the posted URL.
• Never invent media. If the user wants media, use an existing release screenshot/asset or ask for/generate one separately.

Quality Pass

Before final:

• Character count under 280 for each tweet.
• Exact version string and channel.
• Release URL included when requested or expected.
• No unverified claims.
• No more than 3-4 emoji-led bullets in the launch tweet.
• Peter-style concise language; trim filler before trimming facts.

Examples

OpenClaw 2026.4.20 beta 1

🐳 Docker install/update smoke
🖥️ Parallels upgrade checks
🔧 Package verification tightened

Beta first. Stable after the gauntlet.
<release link>

RepoBar 0.5.0 is live

📋 GitHub refs from your clipboard
🔎 Issue, PR, and commit previews
🟢 Open/closed/merged at a glance
🔒 No Accessibility permission needed

Tiny bar, much less mystery.
<release link>

Packaging issue in 2026.4.20-beta.1.

2026.4.20-beta.2 fixes install/update verification. No tag rewrites; beta moves forward.

Upgrade with the beta channel.
<release link>