Architecture Decision Record（ADR）の作成・管理を支援。技術的意思決定の背景・決定・影響をテンプレートに沿って記録する。「ADR を作成したい」「アーキテクチャの決定を記録したい」「技術選定の理由を残したい」「設計判断を文書化したい」といった場面で発動する。意思決定の経緯を記録することで、将来「なぜこの技術を選んだのか」が追跡可能になり、同じ議論の繰り返しを防ぐ。
アーキテクチャ決定記録（ADR）を作成・管理する。技術的意思決定のコンテキスト・決定内容・影響を構造化して記録する。
ADR の価値は「決定そのもの」ではなく「なぜその決定に至ったか」を残すこと。代替案と却下理由を含めることで、将来の見直し時に同じ検討を繰り返さずに済む。
# ADR-NNN: タイトル
簡潔な説明（1 行で決定内容を要約）。
日付: YYYY-MM-DD
## ステータス
提案中 | 承認済み | 廃止 | 置換（ADR-XXX で置換）
## コンテキスト
この決定が必要になった背景・状況を説明。
- 現在の課題や制約
- 関連するシステムやサービス
- ビジネス要件
## 決定
**何を決定したか** を明確に記述。
### 変更箇所
具体的な実装変更がある場合は記載。
### 代替案
検討した代替案とその却下理由。
## 影響
### ポジティブ
- 良い影響
### ネガティブ
- 悪い影響や注意点
## コンプライアンス
決定が正しく実装されていることを確認する方法。
## 備考
- 著者: 担当者名
- 関連コミット: コミットハッシュ
- 関連 ADR: ADR-XXX
| ステータス | 説明 |
|---|---|
| 提案中 | レビュー待ちの ADR |
| 承認済み | 採用された決定 |
| 廃止 | 無効になった決定 |
| 置換 |
| 別の ADR で置き換えられた |
docs/adr/ ディレクトリ内の既存 ADR の最大番号を確認するdocs/index.md と mkdocs.yml を更新する既存の ADR がある場合は docs/adr/ の内容を確認する。ステータス変更や新規 ADR の追記のみを行う。
Example:
ユーザー: 「フレームワークを変更する決定を記録したい」
回答: docs/adr/ の最大番号を確認し、次の連番で ADR を作成する。
既存の関連 ADR があればステータスを「置換」に変更し、
新しい ADR の「コンテキスト」に経緯を記載する。
001 から連番。ファイル名は NNN-kebab-case-title.md 形式（例: 006-cache-strategy.md）docs/adr/。新規作成時は docs/index.md と mkdocs.yml も更新するanalyzing-architecture — アーキテクチャ設計（ADR の主な発生源）analyzing-tech-stack — 技術スタック選定（ADR として記録すべき決定）git-commit — ADR 作成後のコミット