announce-release

name	announce-release
description	xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。

announce-release skill

なぜこの skill があるか

リリースのたびに「何が変わったか」を短くチームへ伝える作業を、毎回その場のプロンプトで指示し直すと、要約の粒度・更新手順の書き方がぶれる。skill 化して周知テキストの型を揃える。

責務は release skill と分ける (= 単一責任): release が「リリースを作る (version 上げ・tag・GitHub Release)」、本 skill が「作ったリリースをチームに伝える」。周知はリリース直後だけでなく後追いでも単独で呼びたい (= 「この期間の分まとめて」) ため、release に混ぜず独立させる。

やること

skill が呼ばれたら以下の Step を順番に実行する。

Step 1: 対象リリースを特定

依頼の範囲 (= 期間 / バージョン範囲 / 「前回の周知以降」) から対象の tag を割り出す。

• tag と日付の一覧: git for-each-ref --sort=-creatordate --format '%(creatordate:short) %(refname:short)' refs/tags
• 「土日」「今週」など期間指定は日付で絞る。「v0.10.0 以降」などバージョン指定は該当範囲の tag を拾う
• 範囲が曖昧なときは勝手に決めない。割り出した tag 一覧を依頼者に見せて認識合わせしてから次へ進む

Step 2: 各リリースの利用者向けセクションを取る

• 各 tag の公開済みリリースノートを取得: gh release view <tag>
• 各リリースノートの 「## ユーザー向け」セクションだけ を材料にする (= 開発者向けは既定で載せない、下記「振る舞いのルール」参照)
• コミットから再要約しない。release skill が既にユーザー向け / 開発者向けを分類済みなので、その分類を信頼して利用者向けだけ拾う
• 対象範囲に 利用者向けの変化が無いリリース (= 「## ユーザー向け」セクションが空 / 無い、開発者向けのみ) が混ざっていたら、周知テキストから落として依頼者にその旨を伝える (= 空エントリで並べない)

Step 3: 短いドラフトにまとめる

• 1 リリースにつき 1〜2 行に圧縮する。見出し行 (= 何が変わったか) + 観測できる変化の一言。利用者が「自分の作業で何が変わるか」を掴める書き方にする (= release skill の「内容の書きっぷり」と同じ基準、内部の実装 how は載せない)
• 末尾に 更新手順を 1 ブロック 添える。対象範囲の最古 → 最新の版を跨ぐ形で書く:
  • apm.yml の依存を最新 tag に書き換える
  • apm install --target claude
  • Content hash mismatch が出たら apm install --update --target claude
• 全体を短く保つ。詳細は GitHub Releases への 1 行リンクで足りる

Step 4: ドラフトを渡す

• コードブロックで出す (= コピペしやすくする)
• 投稿はしない。周知先への貼り付けは依頼者が行う (下記「振る舞いのルール」参照)

振る舞いのルール

利用者向けだけを既定にする

チーム周知の目的は「使う人の作業で何が変わるか」を伝えること。開発者向け (= リポジトリ内部だけの変更) は既定で載せない。依頼者が「開発者向けも入れて」と言えば足す。

投稿はしない (= ドラフト止まり)

周知先チャンネルへの投稿は外向き操作で取り消しにくい。この skill はドラフト生成に留め、投稿は依頼者に委ねる。ドラフト生成はツール非依存で常に動く形を保つ (= 特定の周知ツール連携に依存させない)。

更新手順は README の正規手順に合わせる

更新手順は思い出しで書かず、README の "Update" セクションを正とする。タグを跨ぐ更新は apm.yml の手編集が必要で、apm install --update だけでは #vX.Y.Z の pin を書き換えない (= APM 0.12.x 時点の仕様)。ここを省くと「--update で上がるはず」と試してハマる。README とずれたら README を正とする。

gh を使う (= git-workflow skill の override)

リリースノート本文 (= 利用者向けセクション) は GitHub Release にしかない (tag のメッセージには入らない) ため、gh release view で取得する。git-workflow skill のデフォルト「gh 使わない」を、release skill と同様に意図的に override する。

対象範囲は依頼者と認識合わせ

「土日」「最近」など範囲が曖昧なときは、Step 1 で割り出した tag 一覧を見せて依頼者と認識合わせしてから要約に入る。一方的に範囲を決めて要約しない。

成果物

• チーム周知用の短いドラフト (= 利用者向けの変化 + 更新手順)、コードブロックで提示。投稿は依頼者が行う。