crowi 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 分類ではない — 該当が無いカテゴリはそもそも出さない)。よく使うカテゴリ:
- 破壊的変更: 運用者・クライアント側の対応が要るもの
- セキュリティ: 脆弱性修正・認証境界の変更。主語に注意 — 依存パッケージの脆弱性を「脆弱性 N 件を解消」と書くと Crowi 自体にあったように読める (
crowi-changesetsの「依存パッケージの脆弱性対応の書き方」が正本) - 設計/基盤: アーキ変更・内部契約の変更(ユーザー影響は薄いが技術的に重要なもの)
- 機能: 新しい挙動・UI 変更
- 修正: バグ修正(クラッシュ・不整合・データ破損 等)
- docs: ドキュメントの新規/陳腐化修正(まとまった量があるときだけ独立させる)
各カテゴリ 1 行、項目は読点区切りで詰め込む(改行しない — Discord の返信として読みやすい 密度を優先)。文体は過去ログの実例に合わせる: 体言止め寄り・技術的に具体的・補足は 括弧で短く添える。severity が高いもの(クラッシュ・脆弱性・データ消失)は各カテゴリ内で 先頭に置く。
CHANGELOG の文章をそのまま並べない — あの文体は npm パッケージの利用者向けで、 Discord は社内(仲間内)向けの温度感。エンジニアが実際に話す密度まで凝縮し直す。 実装していない・確認していない話を憶測で書き足さない(CHANGELOG に無い事実は書かない)。
Step 4: 出力
生成したテキストをそのまま会話に提示する(コピペしてそのまま Discord に貼れる形。
Discord の記法に合わせる — 各カテゴリ行は必ず行頭 - で始める(Discord は
行頭 - を箇条書きとして認識してレンダリングする。付けないと単なる太字の段落に
なり箇条書きにならない)。**太字** の見出し + - の行頭 + 項目は 、 区切り、が
基本形:
- **カテゴリ**: 項目1(補足)、項目2、項目3
鉄則
- 投稿はしない。人間がコピペして貼る前提のテキスト生成に徹する。
- CHANGELOG 由来の事実だけを書く。裏取りできない話を書き足さない。
- 1 カテゴリ 1 行を守る。
- 固定カテゴリ数に無理に当てはめない — 該当が無いカテゴリは省く。