Crowi Release Discord Nits (リリース後の一言コメント生成)

CI がリリースごとに Discord へ自動投稿する告知(Crowi Releases bot — release notes リンク + docker pull コマンド)に対して、人間(sotarok)がスレッド内で返信として 載せる一言コメントを生成する skill。「今回のリリースで特に触れておきたい点」を、 カテゴリ別・1 カテゴリ 1 行の簡潔な箇条書きにまとめる。

投稿はしない。生成したテキストを提示するところまでが本 skill の責務で、Discord への貼り付けは人間が行う。理由は 2 つ:このセッションから Discord へ投稿する経路 (webhook・bot トークン等)がそもそも用意されていないことと、たとえ用意されていても 「公開コンテンツの投稿」は常に人間の明示確認を要る行為だから(CLAUDE.md の行動区分)。

起動構文

/crowi-release-discord-nits                    # 直近リリース(最新の v* tag)を対象
/crowi-release-discord-nits v2.0.0-alpha.10     # 対象 tag を明示指定

ワークフロー

Step 1: 対象リリースと比較起点の解決

• 引数が無ければ対象 tag = git describe --tags --abbrev=0 --match 'v*'(最新)。
• 比較起点(1 つ前のリリース)は git tag --list 'v*' --sort=-creatordate で対象 tag の 直前の 1 件を取る。

Step 2: 実際に出荷された変更点の収集(CHANGELOG 差分が正)

.changeset/*.md は pnpm changeset version の時点で消費されて消えるため、「その回に 何が実際に入ったか」の正本はその version 化コミットが書いた各パッケージの CHANGELOG.md — spec や changeset 原文の言い回しではなく、最終的にユーザーに見える 単位でまとまっている。

git diff <比較起点>..<対象 tag> -- 'packages/*/CHANGELOG.md' 'apps/*/CHANGELOG.md'

フィルタなしの生の diff をそのまま読むこと — grep '^+- ' のような 1 行抽出は 使わない。各エントリは +- <hash>: ... で始まるが、元の changeset 本文が手動改行を 含んでいると 後続行が +- を伴わず折り返して続く(実測: ce69b4a の BREAKING エントリが v2 never で切れて次行に続いていた — 先頭行だけ拾うと文が壊れる)。 1 エントリの終わりは次の +- <hash>: 行・次の +### 見出し・空行のいずれかで判断し、 全文を読んでから要約する。

+- Updated dependencies [<hash>] 行(内部の workspace 依存バンプに伴う自動生成 エントリ)はユーザー向けの実質情報を持たないので無視する。

同一 changeset は複数パッケージの CHANGELOG に重複して現れる(1 つの changeset が api と api-contract の両方を bump すれば、ほぼ同じ文面が両方の CHANGELOG.md に 1 エントリずつ載る)。<hash>: の値でユニーク化し、同じ hash は 1 件として扱う (実測: 直近リリースで最大 8 回まで重複した changeset があった)。

Step 3: カテゴリ分けして 1 行に凝縮

集めたエントリを、その回の内容に応じて動的にカテゴリ分けする(固定 4 分類ではない — 該当が無いカテゴリはそもそも出さない)。よく使うカテゴリ:

• 破壊的変更: 運用者・クライアント側の対応が要るもの
• セキュリティ: 脆弱性修正・認証境界の変更
• 設計/基盤: アーキ変更・内部契約の変更(ユーザー影響は薄いが技術的に重要なもの)
• 機能: 新しい挙動・UI 変更
• 修正: バグ修正(クラッシュ・不整合・データ破損 等)
• docs: ドキュメントの新規/陳腐化修正(まとまった量があるときだけ独立させる)

各カテゴリ 1 行、項目は読点区切りで詰め込む(改行しない — Discord の返信として読みやすい 密度を優先)。文体は過去ログの実例に合わせる: 体言止め寄り・技術的に具体的・補足は 括弧で短く添える。severity が高いもの(クラッシュ・脆弱性・データ消失)は各カテゴリ内で 先頭に置く。

CHANGELOG の文章をそのまま並べない — あの文体は npm パッケージの利用者向けで、 Discord は社内(仲間内)向けの温度感。エンジニアが実際に話す密度まで凝縮し直す。 実装していない・確認していない話を憶測で書き足さない(CHANGELOG に無い事実は書かない)。

Step 4: 出力

生成したテキストをそのまま会話に提示する(コピペしてそのまま Discord に貼れる形。 Discord の記法に合わせる — 各カテゴリ行は必ず行頭 - で始める(Discord は 行頭 - を箇条書きとして認識してレンダリングする。付けないと単なる太字の段落に なり箇条書きにならない)。**太字** の見出し + - の行頭 + 項目は 、 区切り、が 基本形:

- **カテゴリ**: 項目1(補足)、項目2、項目3

鉄則

• 投稿はしない。人間がコピペして貼る前提のテキスト生成に徹する。
• CHANGELOG 由来の事実だけを書く。裏取りできない話を書き足さない。
• 1 カテゴリ 1 行を守る。
• 固定カテゴリ数に無理に当てはめない — 該当が無いカテゴリは省く。