Treatment Backend リリースノート生成

Treatment バックエンド リリースノート

実際のリポジトリ証拠に基づき、ソースブランチをターゲットブランチ（特に stage または production）に昇格する際に、監査可能な英語のリリースノートを生成します。リリースノート作成後、会話内でのみ、別途ペルシャ語の見出しサマリー を作成します。ペルシャ語のサマリーをリリースノートやその他のプロジェクトファイルに追加、埋め込み、書き込むことは絶対に行わないでください。

エージェント間実行契約

• このスキルは Codex、OpenCode、Claude Code 間で移植可能です。ベンダー固有のツールは必要ありません。呼び出された際は、この SKILL.md とリンクされた references/ ファイルを参照してください。
• 正規のコピーは .agents/skills/treatment-backend-release-note/ に1つ保存されます。.claude/skills/ と .opencode/skills/ は、バンドルインストーラー使用時に同じコピーを指します。異なるコピーを管理しないでください。
• ツールや権限が利用できない場合は、制限を正確に報告してください。Git の証拠やリリースステータスを捏造しないでください。
• 平文での呼び出し、または Codex では $treatment-backend-release-note、Claude Code および対応する OpenCode 設定では /treatment-backend-release-note を受け付けます。すべての呼び出しは、まったく同じワークフローと出力ポリシーに従います。

入力と範囲

• 必須: source_branch、target_branch（ユーザーが明示的にプロジェクトの慣例を確立している場合のみデフォルトのターゲットを使用。それ以外の場合は、実際に不明なときに質問すること）。
• オプション: リリースバージョン、デプロイウィンドウ、チケット参照、出力ファイル名（docs/releases/ の下に保存）、デプロイ方法、所有者。
• 変更を収集する前に、リモートを検出し、ref、ワーキングツリーの状態、リポジトリルートを検証してください。明示的な許可なしに、ブランチの変更、プル、フェッチ、コミット、マージ、タグ、デプロイ、アプリケーションコードの修正を行わないでください。
• ソース/ターゲットが指定されていない場合は、明確なコンテキストから推測を試みてください（例：ユーザーが「develop を stage にリリースする」と言った場合）。それ以外の場合は質問してください。現在チェックアウトされているブランチがソースであると黙って想定しないでください。
• 両方の ref はローカルブランチまたはリモート追跡ブランチの場合があります。分析された ref とコミットハッシュを正確に明記してください。
• レポートは、ソースブランチでこれまでにコミットされたすべてではなく、ソースによってターゲットに導入された変更 として解釈します。

ワークフロー

1. 事前チェックと Git 証拠

リポジトリルートから、以下のコマンドを検査します（ref 名を安全に適応させ、信頼できないシェル引数を補間しないでください）:

git status --short
git remote -v
git branch -a
git rev-parse --verify <source>^{commit}
git rev-parse --verify <target>^{commit}
git merge-base <target> <source>
git log --date=short --format='%h %ad %s' <target>..<source>
git diff --stat <target>...<source>
git diff --name-status <target>...<source>
git diff <target>...<source> -- <relevant-paths>

target..source は、ターゲットから到達できないコミットを識別します。git diff での target...source はマージベースとソースを比較し、ソースブランチによって提案された変更を近似します。これらは、分岐したブランチ、チェリーピック、リベースの場合の実際のマージ差分と正確に等しくない場合があります。提案されたリリースの場合は、コミットと差分の両方の視点を検査し、異常を特定し、必要に応じて、許可がある場合のみ、使い捨てのワークツリー/一時的なマージを使用します。未確認の三点ドット差分から、確定したマージ結果を断言しないでください。すでに完了したリリースの場合は、可能であれば、記録されたマージコミット、タグ、デプロイされた SHA、または実際のデプロイ前後の ref を優先します。

意味のあるソースファイル、マイグレーション、設定、API スキーマ、シリアライザー、パーミッション、バックグラウンドタスク、統合、テスト、デプロイマニフェストをレビューしてください。コミットサブジェクトのみに依存しないでください。該当する場合はナラティブから生成ファイル/ノイズファイルを除外しますが、影響のある生成されたマイグレーションやロックファイルの変更を隠さないでください。複数のコミットにまたがるビジネス影響のある変更を確認してください。変更されたすべてのファイルをリストするのではなく、ビジネス機能ごとにグループ化してください。実証可能な場合、コードをチケット/PR にリンクしてください。

2. 変更と影響の分類

以下を分離して説明します:

1. ビジネス変更 — 新規または変更されたワークフロー、資格ルール、補償範囲、経費/請求処理、レポート、通知、および観察可能な動作。コード、テスト、またはユーザー提供のプロダクトコンテキストによって裏付けられる場合のみ記述します。推測または確認不足であることを明確にラベル付けします。
2. 技術的変更 — API、Django モデル/マイグレーション、ジョブ/Celery、データベース/インデックス、外部統合、設定、セキュリティ/パーミッション、信頼性、パフォーマンス、可観測性、CI/CD、リファクタリング。
3. 互換性と消費者 — REST エンドポイント/メソッド、リクエスト/レスポンスフィールド、ステータスコード、認証、Web/モバイルクライアント、内部呼び出し元、ワーカー、サードパーティシステム、DB、イベント。「Breaking change: Yes / No / Unknown」を証拠とともに記述します。API 互換性とデプロイ/データ互換性を区別します。該当する場合、必要な消費者アクションとロールアウト順序を説明します。
4. 検証とトレーサビリティ — 正確なソース/ターゲット ref + SHA、ベース SHA、注目すべきコミット、見つかったチケット/PR リンク、テストとその実際の観察されたステータス、マイグレーション計画、提供された場合の承認者/ステータス。テストを実行するか、信頼できるテスト結果を取得せずに、テストが合格したと主張しないでください。
5. 元に戻す / ロールバック — ターゲットに適した手順と前提条件を説明します。アプリケーションのロールバック、リバーシブルなスキーママイグレーション、不可逆なデータマイグレーション、リプレイ可能なジョブ、メッセージ、冪等性、サードパーティの副作用を区別して処理します。常に Git の revert と運用上のロールバックを区別します。マイグレーションと副作用を確認せずに、ロールバックが安全であると断言しないでください。

references/review-checklist.md の完全なチェックリストを確認してください。

3. 英語のリリースノートを作成して保存する

references/release-note-template.md に従ってください。リリースノートに保存されるすべてのコンテンツ（見出しを含む）には英語を使用します。簡潔でありながら情報量が豊富で、エンジニアリングとビジネスの両方のレビューに適したものにします。詳細を捏造するのではなく、「未確認」、「不明」、または「確認が必要」を使用します。

正規のプロジェクト出力ディレクトリは docs/releases/ です。すべてのリリースノートをそこに保存します。ルートレベルの release-notes/ ディレクトリを作成しないでください。デフォルトの出力は docs/releases/YYYY-MM-DD-<source>-to-<target>.md で、ブランチのスラッシュはハイフンに置き換えられます。明示的に要求されたファイル名を尊重しつつ、それを docs/releases/ の下に保持します。既存のリリースノートの上書きを避けてください。保存先が存在する場合は、一意のファイル名を選択するか、置き換えの明示的な承認を求めてください。生成日のみをドキュメント日付として使用し、捏造されたデプロイ日付として使用しないでください。リリースノートは、デプロイが確認されるまで、提案されたリリースです。

保存後、ファイルを読み戻して検証します: ブランチの方向とコミット ID、ビジネス/技術的変更、互換性、検証、トレーサビリティ、ロールバック、ペルシャ語のサマリーがないこと。要求されない限り、リリースノートを自動ステージングまたはコミットしないでください。保存された相対パスを報告してください。

4. チャットのみのペルシャ語サマリー（必須）

保存と検証が成功した後にのみ、最終的なエージェント応答で、ペルシャ語による簡潔な見出しスタイルのサマリーを提示します。ビジネスが読み取れる成果、意味のあるリスク、必要な消費者/デプロイアクション、準備状況/未知の事項に焦点を当てます。通常は3～7個の短い箇条書きで、必要がない限り低レベルの実装詳細は含めません。フォーマット例:

خلاصه برای ارائه به بیزینس (فقط در پاسخ Agent، خارج از فایل):
- بهبود فرآیند ...
- تغییر در رفتار ...
- نیاز به هماهنگی با ...
- وضعیت اعتبارسنجی: ...
- ریسک و برنامه بازگشت: ...

レビュー中に確立されたステートメントのみを含めます。このサマリーをファイル、ログ、コミットメッセージ、リリースノートの付録に保存しないでください。書き込みに失敗した場合は、リリースノートが登録されたと主張せず、障害を説明し、必要に応じて、暫定的であることを明確にマークした暫定サマリーを提供します。

品質管理基準

• すべての変更と主張は、検査された差分、テスト、Git 履歴、または明示的に提供されたリリースコンテキストに基づいてください。検証された事実と推測を区別してください。
• 差分で見つかったシークレット、トークン、パスワード、プライベートな顧客データ、生の認証情報を出力しないでください。例を編集/伏せ字にしてください。
• コミットされたコードをデプロイされた機能と同一視せず、未実行のテストを合格したテストと同一視しないでください。
• ブランチに関係のない変更が含まれている場合は、重要な変更を黙って削除するのではなく、範囲とリスクを文書化してください。
• 確認した後でのみ明示的に None identified を使用し、それ以外の場合は Unknown / Not verified を使用します。
• 文書化の一環として、マイグレーションの実行、本番データの操作、またはロールバックを決して行わないでください。