| name | adr-template |
| description | ADR（Architecture Decision Record）作成を支援するテンプレートスキル。
docs/adr/ へのADR作成時に自動適用され、
06_DECISION_MAKING.md の3 Agents Modelに準拠した構造を提案する。
アーキテクチャ決定、技術選定、設計方針の記録時に活用される。
|
| version | 1.0.0 |
| paths | ["docs/adr/*.md"] |
| when_to_use | ADR を新規作成するとき、技術選定・アーキテクチャ決定・設計方針を記録するとき。docs/adr/ にファイルを作成する場面で活用する。 |
| allowed-tools | Read, Write, Edit |
ADRテンプレートスキル
目的
このスキルは、ADR（Architecture Decision Record）作成時に一貫した構造と3 Agents Modelによる多角的検証を確保するためのテンプレートを提供する。
適用条件
以下のいずれかに該当する場合、このスキルを適用する:
docs/adr/ への新規ファイル作成- アーキテクチャ決定、技術選定の記録を求められた
- ADR の作成を求められた時
ファイル命名規則
docs/adr/
├── 0001-initial-architecture.md
├── 0002-database-selection.md
├── 0003-api-design-pattern.md
└── ...
形式: NNNN-kebab-case-title.md
- NNNN: 4桁の連番（0001から）
- タイトル: ケバブケースで簡潔に
ADRテンプレート
# ADR-NNNN: [決定タイトル]
## メタ情報
| 項目 | 内容 |
|------|------|
| ステータス | Proposed / Accepted / Deprecated / Superseded |
| 日付 | YYYY-MM-DD |
| 意思決定者 | [名前/ロール] |
| 関連ADR | [ADR-XXXX](./XXXX-*.md) |
## コンテキスト
### 背景
[この決定が必要になった背景、課題]
### 制約条件
- [技術的制約]
- [ビジネス制約]
- [リソース制約]
### 要求事項
- [満たすべき要件1]
- [満たすべき要件2]
## 検討した選択肢
### Option A: [選択肢名]
**概要**: [簡潔な説明]
**メリット**:
- [利点1]
- [利点2]
**デメリット**:
- [欠点1]
- [欠点2]
### Option B: [選択肢名]
**概要**: [簡潔な説明]
**メリット**:
- [利点1]
**デメリット**:
- [欠点1]
### Option C: [選択肢名]
...
## 3 Agents Analysis
### [Affirmative] 推進者の視点
> 最高の結果はどうなるか？どうすれば実現できるか？
- [採用時のメリット、可能性]
- [開発効率への貢献]
- [ユーザー価値への貢献]
### [Critical] 批判者の視点
> 最悪の場合どうなるか？何が壊れるか？
- [リスク、懸念点]
- [エッジケース、失敗シナリオ]
- [技術的負債の可能性]
- [セキュリティ懸念]
### [Mediator] 調停者の視点
> 今、我々が取るべき最善のバランスは何か？
- [両視点の統合]
- [リスク緩和策]
- [段階的導入の提案]
## 決定
**採用**: Option [X]
### 決定理由
[なぜこの選択肢を採用したか]
### 却下理由
- **Option [Y]**: [却下した理由]
- **Option [Z]**: [却下した理由]
## 影響
### ポジティブな影響
- [良い影響1]
- [良い影響2]
### ネガティブな影響
- [悪い影響1]（緩和策: [対策]）
### 影響を受けるコンポーネント
- `src/[path]`: [影響内容]
- `docs/specs/[file]`: [更新必要]
## 実装計画
### フェーズ1: [フェーズ名]
- [ ] [タスク1]
- [ ] [タスク2]
### フェーズ2: [フェーズ名]
- [ ] [タスク3]
## 検証方法
- [この決定が正しかったかを検証する方法]
- [見直しのトリガー条件]
## 参考資料
- [参考リンク1]
- [参考リンク2]
ADRステータスの遷移
Proposed → Accepted → [Deprecated | Superseded]
↓
Rejected
| ステータス | 説明 |
|---|
| Proposed | 提案中、レビュー待ち |
| Accepted | 承認済み、実装可能 |
| Deprecated | 非推奨、新規採用不可 |
| Superseded | 新しいADRに置き換え |
| Rejected | 却下 |
ADR作成ワークフロー
-
起案
- コンテキストと選択肢を整理
- ステータス:
Proposed
-
3 Agents 分析
- Affirmative: メリットを最大化
- Critical: リスクを洗い出し
- Mediator: バランスを取る
-
レビュー
- ステークホルダーからのフィードバック
- 選択肢の追加・修正
-
決定
-
実装追跡
既存ADRの更新
Supersede（置き換え）の場合
旧ADR:
## メタ情報
| ステータス | Superseded by [ADR-XXXX](./XXXX-*.md) |
新ADR:
## メタ情報
| 関連ADR | Supersedes [ADR-YYYY](./YYYY-*.md) |
/ship からの自動起票フロー（v4.0.0）
/ship Phase 2 で PM級の設計判断が検出された場合、ADR 起票を提案する:
/ship Phase 2 (Doc Sync チェック)
→ PM級の変更を検出
→ 「ADR を起票しますか？」とユーザーに提案
→ 承認 → ADR テンプレートを適用し、変更内容をコンテキストとして渡す
→ スキップ → ADR 起票なしで /ship を続行
この連携により、PM級の設計判断が暗黙的にコードベースに埋もれることを防ぐ。
参照ドキュメント
docs/internal/06_DECISION_MAKING.md.claude/rules/permission-levels.md（PG/SE/PM 分類基準）/ship コマンド (Phase 2: Doc Sync チェック)
