release-tweet

name	release-tweet
description	GitHub Release のリリース告知ツイート草案(X / Bluesky 等の長文 SNS 向け)を生成する(投稿はしない)。「リリース告知ツイート」「リリースのツイート文作って」「/release-tweet [<tag>]」で発動。

release-tweet — リリース告知ツイート草案スキル

Overview

直近もしくはユーザー指定の GitHub Release を起点に、SNS 投稿用の告知文を草案する。

• ネタの起点は gh release view <tag> で取得するリリースノート（GitHub が自動生成した PR ベースの分類）
• フォーマットは takt 作者の告知ツイートを参考にした「テーマ絵文字 + 散文ブロック + 末尾の bug-fix 箇条書き」スタイル
• 投稿はしない。草案を会話に提示するのみ
• 文字数制限は仮定しない（X premium / Bluesky / Mastodon を主な想定）

When to Use

• 新規 GitHub Release を作った直後にユーザーが告知文を欲しがったとき
• 「リリース告知ツイート」「リリースのツイート文作って」「X 告知文」「Bluesky 用に書いて」等の発話があったとき
• /release-tweet または /release-tweet <tag> で明示的に起動されたとき

Prerequisites

• gh が認証済みであること（gh auth status で OK）
• カレントディレクトリが GitHub リポジトリの作業ツリー内であること（gh repo view が成功する）
• 対象リポジトリに GitHub Release が 1 件以上存在すること

GitHub Release が 0 件の場合は次のメッセージを表示して終了：

release-tweet スキルは GitHub Release を起点に告知文を生成します。対象リポジトリに Release が存在しないため終了します。/release で Release を作成してから再実行してください。

パイプライン

Step 1: 対象 Release の特定

引数が与えられていれば（例: /release-tweet v0.8.1）、そのタグを対象とする。タグが存在しなければエラーで終了。

引数がなければ最新の Release を対象とする：

gh release list --limit 1 --json tagName -q '.[0].tagName'

Step 2: コンテンツ収集

gh repo view --json name,description -q '{name, description}'    # プロジェクト名・概要
gh release view <tag> --json tagName,name,body,publishedAt,url    # Release ノート本体

body には GitHub が自動生成した PR ベースの一覧が含まれる（* PR タイトル by @author in #N 形式）。 必要に応じて主要 PR の本文を gh pr view <N> --json title,body で個別に深掘りして、散文化の材料にする。

Step 3: 分類

各 PR / コミットを次の 3 カテゴリに分類する：

カテゴリ	内容	出力形式
主要（user-facing）	新機能 / 体感改善 / 重要なバグ修正	テーマ絵文字付き散文ブロック（見出し + 2-3 文）
実験的	experimental / preview / beta 等	🧪 + 散文ブロック
その他・内部	軽微な修正 / 内部リファクタ / 開発環境 / CI	🔧 + 箇条書き

判断に迷う場合：

• ユーザーが触る挙動が変わる → 主要
• ドキュメント・テスト・lint・CI など開発者体験のみ → その他
• README に "experimental" や "preview" の語があれば → 実験的

Step 4: 草案生成

下記「Style Guide」に従って 1 つのツイート文を組み立て、会話にそのまま提示する。コードブロックではなく、ユーザーがそのままコピペできる地の文として出力する。

提示後に「絵文字を変える / 散文をもっと短く / URL も付ける / 英語版も欲しい / 別 SNS 向けに整える」などの調整要求に応える。

Style Guide

このセクションがツイートの「声」を決める。トーンを変えたいときはここを編集する。

全体構造

<theme-emoji> <project-name> <tag> リリース

<theme-emoji> <主要 1 の見出し>
<2-3 文の散文。何が変わったか + なぜ嬉しいかを書く>

<theme-emoji> <主要 2 の見出し>
<2-3 文の散文>

...

🧪 <実験的機能の見出し>           # 該当があれば
<2-3 文の散文>

🔧 その他                          # 該当があれば
- <短い 1 行>
- <短い 1 行>

末尾に URL を含めない（ユーザーが「URL も付けて」と明示したときだけ追加する）。 ハッシュタグも含めない（同上）。

テーマ絵文字の選び方

リポジトリの性質を見て、1 つのテーマ絵文字を選び、見出し行で繰り返し使う。例：

ジャンル	推奨
音楽・指揮系	🎼 / 🎵
文書・Markdown	📝 / 📄 / 📖
開発ツール・CLI	🛠 / 🧰 / ⚙️
データ・分析	📊 / 📈
Web・ブラウザ	🌐 / 🪟
汎用デフォルト	📦

ユーザーが好みを指示したらそれを優先する。実験的セクションは 🧪、その他は 🔧 で固定。

トーン

• 機能の宣伝口調を抑え、何が変わったかを淡々と述べる
• 散文は 2-3 文。最初の 1 文で「何」、続く 1-2 文で「どう嬉しいか / どんな副作用があるか」
• 体言止めではなく文末は「〜しました / 〜できます / 〜になりました」
• 過度な絵文字（散文中の装飾絵文字）は使わない。テーマ絵文字は見出し冒頭のみ

例（specv v0.8.1 で生成した実物）

📝 specv v0.8.1 リリース

📄 Source ビュー・コードブロックにコピーボタン
プレビュー画面の Source ビューと、レンダリングされたコードブロックの両方にコピーボタンを追加しました。スクロールしてもボタンが追従するので、長いソース・コードでも先頭まで戻らずコピーできます。

📄 複数インスタンスの同時起動に対応
specv を複数のディレクトリで同時に立ち上げた際、最後の起動内容で他のタブが上書きされる問題を解消しました。それぞれのインスタンスが独立した状態で動作します。

🔧 その他
- ディレクトリ構成を整理し、shared/types.ts に API レスポンスと SSE イベント型を集約しました (#69)
- エラーハンドリングを統一し、サーバー・クライアント間の例外伝播を明示化しました (#66)

エラーハンドリング

状況	対応
gh 認証エラー	gh auth login を案内して終了
カレントディレクトリが GitHub リポジトリでない	エラー表示して終了
Release が 1 件も存在しない	Overview の案内文を出して終了
指定タグの Release が存在しない	gh release list で利用可能なタグを表示して終了
body が空（--generate-notes なしで作成された Release）	代替として gh pr list --state merged --base main --search "merged:>=<prev-release-date>" から再構成し、その旨ユーザーに伝える

Rules

• 投稿はしない。草案を提示するのみ
• 文字数制限は仮定しない（X premium / Bluesky / Mastodon を主想定）
• URL・ハッシュタグは既定で含めない。ユーザーが要求したら付ける
• テーマ絵文字は 1 種類に統一して見出しで繰り返す。実験的は 🧪、その他は 🔧 固定
• 主要セクションは散文（2-3 文）、その他は箇条書きと使い分ける
• 結果はコードブロックではなく地の文で出力し、ユーザーがそのままコピペできる状態にする
• Style Guide はスキル内に独立セクションとして置き、トーン調整はここを編集して行う