release-notes

リリースノート

開発作業を、プロジェクトマネージャーが30秒で確認できるリリースノートにまとめます。各項目では、PM、QA、運用担当者に何が変わったのか、なぜ変わったのか、何が良くなったのかを伝えます。すでに完了した作業だけを要約し、計画を立てたり、課題を登録したり、コードをレビューしたりすることはありません（それらは/feature-prompt、/qa、/code-reviewの役割です）。

執筆ルール

すべての文について、「PMやQA担当者が開発者に聞かなくても理解できますか？」と確認してください。

1. 日常的で分かりやすい言葉を使います。 専門用語、企業的な言い回し、エンジニアリング用語は使いません。
   • 悪い例：「各 RFID 検索の前にスキャンの準備方法を標準化しました」
   • 良い例：「スキャンを始める前に、アプリがスキャナーの準備状況を確認するようになりました」
2. ユーザーに見えること、またはユーザーが行うことを書きます。 画面、ボタン、フィールド、ページの名前を挙げます。
3. 箇条書き1つにつき内容は1つ、短い文を1文だけにします。 段落にはしません。「問題／変更／影響」各セクションの内容は最大2項目です。ラベル付きの変更箇所：、簡単なロジックの説明：、必要な対応：の行は数えません。項目がそれ以上必要なら、詳細が多すぎます。
4. 機能名には完了した作業を表す言葉を使います。 コードには「スキャナー準備状況の確認」、完了した計画書には「ログイン計画の文書化」を使います。
5. 問題＝ユーザーが経験したこと（コードに何が足りなかったかではなく、症状）です。影響＝今、具体的に何が良くなったかです。
6. 余分な言葉や抽象的な表現は避けます。 「正式に」、「するために」、「注目すべき点は」、「これにより確実になります」、リスク低減を述べる表現は削除します。
7. エンジニアリングの内容を、運用上の意味に置き換えます。 コードレベルの詳細は、ユーザーから見た効果として書き換えます（「useRfidScannerをリファクタリング」→「各スキャンの前に、アプリが同じ手順でスキャナーを設定するようになりました」）。ユーザーが技術的な詳細を求めていない限り、説明文にコードの識別子を含めません。
8. 説明の箇条書きは15語以内にします。 抽象的な専門用語は、具体的な動作に置き換えます。QAがテスト対象を特定するために必要な場合は、UIの正確なラベルや技術名をそのまま残します。必須のQA前提条件や順序付きの手順は、短くすると曖昧になる場合、15語を超えてもかまいません。
9. ロジックを変更した場合は、小学5年生にも分かる文を「変更」セクションに1文追加します。 簡単なロジックの説明：<文>
10. 正式な文書ではなく、今日やったことを同僚に話すように書きます。

変更内容を述べずに「強化しました」「最適化しました」「改善しました」のような曖昧な動詞を使わないでください。正確な数値がない場合は、実際に確認された動作に基づき、どのような方向に影響したかを説明します。ワークスペース、Git の履歴、またはユーザーが提供した情報で裏付けられない内容は記載しません。

生成モード

• 日付ベース（日付または期間） — ローカルの Git 履歴を日付で絞り込み、プロジェクトごとにまとめ、コミットを分類します。
• セッションの要約 — セッション中に変更されたファイル、メモ、差分を組み合わせ、論理的な改善点にまとめます。
• 機能の要約 — 機能に関するコミットを、問題 → 変更 → 影響という1つの流れで説明します。
• バージョン範囲（v1.3.0..v1.4.0、または「前回のリリース以降」） — git tag --sort=-version:refnameでローカルタグを確認し、<from>..<to>のログを取得します。ファイル名には<to>タグのコミット日を使います。ローカルタグがない場合はその旨を伝え、取得は行いません。

エビデンスの収集

git fetch、git pull、またはローカルの Git 状態を変更する操作は実行しないでください。 日付、機能、バージョンの履歴については、 references/git-collection.md を読み込んでください。リポジトリの特定、祖先関係、リリースに関する主張、差分に基づくグループ化について説明しています。 セッション内のみの作業では、セッションノート、変更されたファイル、関連する差分を使用します。コミットまたはリリースのエビデンスが必要な場合に限り、Git のリファレンスを読み込んでください。

Project Matrix の完全な PROJECT-CODE を常に使用してください。あるプロジェクトの規約、トークン、コンポーネントを別のプロジェクトに混在させないでください。

サブエージェント：独立した作業にはローカルレーンを自動的に割り当ててください。クラウドエージェントは使用しないでください。割り当て時にレーン数を伝え、各レーンの完了時に報告してください。各レーンはハッシュ、ファイル、ユーザーに見える変更、グループ分け、不確実性の要約を返します。クラスタリング、文面、QA 手順、ファイル出力はメインセッションが担当します。

フェーズが切り替わるたびに Stage / Found / Next / Needs user を出力してください。各項目は1行にしてください。

出力形式

モードに対応したアセットのスケルトンに沿って、Markdown ファイルを1つ作成します。各スケルトンが唯一の形式の参照元です。

• 日付ベース／日付範囲／バージョン範囲／機能モード → assets/release-notes-template.md
• セッション概要 → assets/session-summary-template.md

記入例は references/examples.md にあります。項目の書き方に迷った場合は読み込んでください。

記入ルール：

• Stakeholder Summary は30秒で概要を把握するための欄です。各 PROJECT-CODE を見出し記法なしで単独の行に記載し、機能ごとに「Summary」と「Change」を1文にまとめた箇条書きを1つ記載します。日付のないセッション概要では Date: の行を省略します。
• 1つのプロジェクトに複数の機能がある場合は、機能ブロックを繰り返します。機能セクションはプロジェクト見出しの下に配置します。
• Manual QA Steps：機能ごとに、実用的な手順を3～5個記載します。各手順は Action -> Expected Result の形式とし、主要な正常系とエッジケースを1つ含めてください。まずローカルのセットアップ、ロール、テストデータを記載し、提案する確認と実施済みのテストを区別します。ドキュメントやツールのみの変更では、確認する実際のファイルまたはコマンドを記載してください。存在しない画面や、確認していない結果を作り出さないでください。
• 選択した範囲内で変更が1つ以上確認されたプロジェクトのみを含めます。
• ユーザーに見える詳細は、Change の下にある任意の What changed where: 行に記載します。コミット／差分から判明する場合に限り、設定、ページ／画面、要素、ルートを記載します。判明しない場合は、この行を省略します。
• 任意の Action needed: 行は、Impact の下に記載します。再ログイン、新しい設定、移行、環境変数キーなど、ユーザーまたは運用担当者が行う必要のある作業を記載します。差分から必要な作業がないとわかる場合は、この行を省略します。
• コミットハッシュは Commits Included の下にのみ、箇条書きで1つずつ記載します。コミットのないセッションでは、セッション用スケルトンの (uncommitted session work) が代わりになります。

ファイルの出力

<artifacts-root>/specs/release-notes/ に保存します。

帰属情報を一切付けないでください。コミット、PR、課題コメント、リリースノート、生成ドキュメント、設定、コードコメントに、共同作成者、AI、ツールの帰属情報を追加したり残したりしないでください。

<artifacts-root> の解決方法：*.code-workspace が存在する場合はそのディレクトリ、そうでなければコンテキストごとのルート（リポジトリルートの GLOSSARY-MAP.md、旧形式の CONTEXT-MAP.md）、それもなければリポジトリルートとします。 ワークスペースファイルもマッピングされたコンテキストルートもない場合は、対象範囲内のリポジトリを個別に解決し、リポジトリごとに1つのファイルを作成します。マッピングされたコンテキストでは解決済みのルートを使い、リポジトリ単位の代替ルートに置き換えないでください。

ファイル名 — D-Month-YYYY。先頭にゼロを付けず、英語の月名は先頭を大文字にします： 10-March-2026.md。日付範囲の場合：10-March-2026-to-12-March-2026.md。

• 機能の概要には機能名ではなくリリース日を使用します。日付が指定されておらず、ユーザーが明確に現在のセッションの日付を指しているわけでもない場合は、質問してください。ユーザーが不在の場合は現在のローカル日付を使用し、その前提を冒頭に記載します。
• 「今日」／「現在のセッション」→ 現在のローカル日付。
• ファイル名に NNNN、-release-notes、機能スラッグを追加しないでください。リリースノートは ADR／プロンプトの NNNN シーケンスを共有しません。

競合への対応：既存の内容を保持します。許可された更新を適用する際は、無関係な項目を削除しないでください。置き換えに未解決のユーザー判断が必要な場合は、次に未使用の (2) 形式の別ファイルを作成し、そのパスを伝えてください。確認されていない手編集を上書きしたり、無関係なファイルを削除したりしないでください。

完了条件

• 保存したファイルが、概要の箇条書きとセクションの上限を満たしていること。QA 手順では、必要なセットアップと順序を維持すること。
• 各ファイルが、解決された日付、日付範囲、または未使用の番号付き別ファイルのパスに存在し、読み込んだひな形の構造と一致すること。変更されたプロジェクトのみを含めること。
• 各まとまりに、根拠のある提供状況が記載されていること。「提供済み」とする場合はリリースの根拠を示し、マージされていない作業は進行中と記載すること。
• 少なくとも1つの箇条書きで、影響を受けるワークフローまたはチームを明記すること。
• すべての手動 QA 手順を、実在する UI の場所、ファイル、またはコマンドを含む「操作 -> 期待される結果」の形式で記載すること。「影響」では完了した作業と期待される効果を区別すること。
• 返信では保存した各ファイルのパスを示し、末尾を Suggested next skills (optional) とすること。提案は1～3件とし、必須条件にしないこと。