write-release-notes について
プロジェクト固有のルールに沿ってリリースノートを作成するスキルです。各チャンネルの履歴とリポジトリの変更を集め、公開やコミットは行わず、インストールする人向けの説明を作成します。
主な機能
- 01プロジェクト固有のリリース指示を確認
- 02チャンネルのマニフェストと変更履歴を収集
- 03バージョンとファイル形式の規則を順守
- 04ユーザーに見える変更を中心に記述
- 05公開とコミットはユーザーに委ねる
活用シーン
- 01プロジェクトのチャンネル向けリリースノート作成
- 02公開済みビルド以降の変更を要約
- 03リリースバージョンと記述子の要件を確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/write-release-notesを入力して読み込まれたか確認します。
詳細
リリースノート
プロジェクトがルールを定めます。バージョンの進め方、公開済みマニフェストの保存場所、記述子の形式、そしてその説明文の書き方です。このスキルではコンテキストを集め、それらのルールを推測で済ませず、確実に守ります。
手順を確認する
まず、プロジェクトのリリース作成手順を確認してください。最初に releases/WRITING.md を確認し、続いて AGENTS.md、CONTRIBUTING.md、または releases/README.md で指定されているファイルを確認します。手順が見つからない場合は、そこで止めて質問してください。リリースの説明がどこにあるかを尋ね、バージョン方式やファイル形式を勝手に決めてはいけません。
ユーザーがチャネルを指定しておらず、手順に複数のチャネルが定義されている場合は、どのチャネルにするか尋ねてください。質問は1つにし、選択肢としてチャネルを提示します。
コンテキストを集める
依頼に含まれている場合を除き、以下を自分で集めてください。
- 各チャネルで公開されている内容。手順で指定されているマニフェストの保存場所を確認します。説明されている方法でキャッシュを回避してください（通常は新しいクエリパラメーターを使います）。マニフェストが見つからない場合は、そのチャネルでは一度も公開されていないことを意味します。ネットワーク障害は同じ意味ではありません。報告し、履歴が空だと扱わないでください。
- このツリーの状態：
git rev-parse --short HEAD、本日の日付（UTC、date -u +%Y%m%d）、およびgit status --porcelainを確認します。ツリーに未コミットの変更がある場合、そこからビルドしたものは HEAD と一致しないため、その旨をユーザーに一言伝えてください。 - そのチャネルで公開済みのコミット以降の変更内容：
git log <published>..HEADを実行し、ユーザーが気づく変更を確認します。変更履歴の読者向けに書かれたコミットメッセージ（commit-changesを参照）が情報源です。説明で不明な点は diff で確認します。
作成する
バージョンの選び方、ファイル名、形式について、手順に正確に従ってください。公開担当者が記述子の正確なパスやバージョンを指定している場合は、日付やマニフェストがその後変更されていても、その指定を変更せずに使用してください。
リリースをインストールする人に向けて書きます。新たにできること、ユーザーが遭遇していた可能性のある問題の修正内容、ユーザー側で変わったことを説明してください。ユーザーから見てわかる変化がない限り、内部リファクタリングは記載しないでください。
完了
選んだファイルとバージョンを、そのバージョンを選んだ理由を1行添えて示してください。依頼されない限りコミットせず、公開、タグ付け、プッシュは絶対に行わないでください。リリースはユーザーが行います。