Release Tweet

Release Tweet Skill

Compose a release announcement tweet from GitHub release notes. This skill fetches the release, summarises changes, identifies contributors, cross-references X/Twitter handles, and outputs composed text for review. It does NOT post the tweet.

Workflow

Step 1 — Fetch release notes

Determine the repository from the current working directory or user input.

If the user specifies a tag:

gh release view <tag> --repo <owner/repo>

If no tag is given, find the latest release:

gh release list --repo <owner/repo> --limit 1

Then fetch its body:

gh release view <tag> --repo <owner/repo>

Extract the release body markdown for processing.

Step 2 — Summarise changes as tweet bullets

Parse the release markdown sections (Added, Changed, Fixed, Removed) and rewrite each item as a concise, outcome-focused bullet:

• One line per bullet
• Merge related items where possible
• Drop purely internal items that don't matter to end users
• Keep the list to a reasonable length for a tweet (aim for 5-10 bullets max)
• Use backticks for CLI commands, tool names, and code references
• Focus on what the user gains, not implementation details

Step 3 — Identify external contributors

Scan release notes for attribution patterns like by [@username](https://github.com/username).

Extract GitHub usernames, then determine the repo owner:

gh api repos/<owner>/<repo> --jq '.owner.login'

Filter out:

• The repo owner
• Bot accounts (e.g. dependabot, github-actions)

The remaining usernames are external contributors.

Step 4 — Cross-reference X/Twitter handles

For each external contributor, run the multi-signal verification procedure documented in references/handle-verification.md.

Classify each result as high confidence or low confidence.

Step 5 — Compose the tweet

Assemble the tweet using the template and rules in references/tweet-format.md.

Output

Present two things to the user:

1. The composed tweet text — ready to copy and post 2. A confidence table — showing each contributor's GitHub handle, resolved X handle (if any), confidence level, and reasoning

Example confidence table:

The user reviews everything and posts manually.

X/Twitter Handle Verification Procedure

For each external contributor identified from the release notes, run the following signals in order. Use all available signals before making a confidence determination.

Signal 1 — GitHub twitter_username field

gh api users/<username> --jq '.twitter_username'

If this returns a non-null, non-empty value, this is the contributor's self-declared X handle. This is the strongest signal available.

Signal 2 — Same-handle check

Search the web for site:x.com/<github_username> to determine whether an X account with the same handle exists.

If the account exists, note it as a candidate but do not assume it's the same person without corroboration.

Signal 3 — Blog/website cross-reference

Fetch the contributor's GitHub profile fields:

gh api users/<username> --jq '{name: .name, blog: .blog, bio: .bio}'

If they have a blog or personal website, look for links to an X/Twitter profile on that site. If their real name appears on both the X profile and the GitHub profile, that's a corroborating signal.

Signal 4 — Contextual fit

Check whether the candidate X account's bio, posts, or focus area aligns with the project's domain (e.g. iOS development, mobile tooling, Swift).

A mismatch (e.g. the X account is about cooking) is a strong negative signal.

Confidence Classification

High confidence

Assign high confidence when ANY of these conditions are met:

• GitHub twitter_username field is set (Signal 1)
• Multiple signals corroborate: same handle exists (Signal 2) AND contextual fit matches (Signal 4) AND website cross-reference confirms (Signal 3)

Low confidence

Assign low confidence when:

• Only one weak signal is present (e.g. same handle exists but no corroboration)
• The X profile doesn't clearly match the contributor

No match

If no signals produce a candidate, record the contributor with no X handle and skip them in the tweet's @mention list. Use their plain name or GitHub username instead.

Output

For each contributor, record:

• GitHub username
• Resolved X handle (if any)
• Confidence level (high / low / none)
• Brief reasoning citing which signals were used

Tweet Format Reference

Template

<Project> <version> is out!

<Optional intro line>

<Bullet list of changes>

<Install/upgrade reminder>

<Contributor shout-out>

Rules

Title line

• Format: <Project> <version> is out!
• Example: XcodeBuildMCP v2.1.0 is out!

Intro line (optional)

• A short phrase setting context when warranted (e.g. "Big update!:" or "Lots of improvements:")
• Omit if the bullet list speaks for itself

Bullet list

• Each bullet is concise and outcome-focused
• Use backticks for CLI commands, tool names, and code references
• Start each bullet with an emoji-free dash or bullet character
• Keep to 5-10 bullets maximum

Install/upgrade reminder

• Include only if there's a standard install/upgrade path
• Example: brew install xcodebuildmcp or npm update <package>
• Omit if no obvious install command exists

Contributor shout-out

• Format: "Shout out to @handle1, @handle2, and @handle3 for their contributions!"
• High-confidence contributors: use @handle (their X/Twitter handle)
• Low-confidence contributors: use their plain text name or GitHub username without @
• If no external contributors, omit this section entirely

Tone

• Enthusiastic but professional
• No marketing fluff or hyperbole
• No hashtags unless the user specifically requests them
• Direct and informative