architecture-decision-records

Topics in the source

• アーキテクチャ決定記録
• アクティベーション時期
• ADR形式
• ワークフロー
• 新しいADRをキャプチャする
• 既存のADRを読む
• ADRディレクトリ構造
• ADRインデックス形式

コーディングセッション中にアーキテクチャ決定を構造化ドキュメントとして記録します。決定がSlackスレッド、PRコメント、または誰かの記憶にのみ存在する代わりに、このスキルはコードと並行して存在する構造化ADRドキュメントを生成します。 ユーザーが明示的に「この決定を記録しよう」または「このADRを作成しよう」と言う 重要な代替案の選択（フレームワーク、ライブラリ、パターン、データベース、API設計） ユーザーが「私たちは...を選択した」または「YではなくXをしている理由は...です」と言う ユーザーが「なぜXを選んだのか」と尋ねる（既存のADRを読む） アーキテクチャ上のトレードオフが検討される計画段階 Michael Nygardによって提案されたADR形式を、AI支援開発向けに調整したものを使用します： 決定の瞬間が検出されたとき： 1. 初期化（初回のみ） — docs/adr/が存在しない場合、ユーザーの確認を得た上でディレクトリ、インデックステーブルヘッダーでシードされたREADME.md（下記のADRインデックス形式を参照）、手動使用用の空白のtemplate.mdを作成します。明示的な同意なしにファイルを作成しないでください。 2. 決定を特定する — 行われている中核的なアーキテクチャの選択を抽出する 3. コンテキストを収集する — この問題を起こした背景は？存在する制約条件は？ 4. 代替案をドキュメント化する — どの他のオプションが検討されたか？ なぜ拒否されたか？ 5. 結果を述べる — トレードオフは何か？何がより簡単/難しくなるか？ 6. 番号を割り当てる — docs/adr/内の既存のADRをスキャンして増分する 7. 確認して書き込む — レビュー用のドラフトADRをユーザーに提示します。明示的な承認後にのみdocs/adr/NNNN-decision-title.mdに書き込みます。ユーザーが辞退した場合、ファイルを書き込まずにドラフトを破棄します。 8. インデックスを更新する — docs/adr/README.mdに追記する ユーザーが「なぜXを選んだのか」と尋ねたとき： 1. docs/adr/が存在するかチェック — 存在しない場合、「このプロジェクトでADRが見つかりません。アーキテクチャ決定の記録を始めたいですか？」と応答 2. 存在する場合、関連エントリのdocs/adr/README.mdインデックスをスキャン 3. 一致するADRファイルを読み、ContextとDecisionセクションを表示 4. 一致が見つからない場合、「その決定についてのADRが見つかりません。今すぐ記録しますか？」と応答 会話の中でアーキテクチャ決定を示すこれらのパターンに注意： 明示的なシグナル 「Xにしよう」 「Yでは

This is an excerpt. Refer to the complete source and its current requirements.