| 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
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 はスキル内に独立セクションとして置き、トーン調整はここを編集して行う
