| name | architecture-decision-records |
| description | Capture architectural decisions made during Claude Code sessions as structured ADRs. Auto-detects decision moments, records context, alternatives considered, and rationale. Maintains an ADR log so future developers understand why the codebase is shaped the way it is. |
| origin | ECC |
Architecture Decision Records
コーディングセッション中に行われたアーキテクチャ上の決定を記録します。決定が Slack スレッド、PR コメント、誰かの記憶の中だけに存在するのではなく、このスキルはコードと共存する構造化された ADR ドキュメントを生成します。
起動条件
- ユーザーが明示的に「この決定を記録しよう」や「ADR にして」と言った場合
- ユーザーが重要な選択肢の間で選択する場合（フレームワーク、ライブラリ、パターン、データベース、API 設計）
- ユーザーが「X にすることにした...」や「Y ではなく X にする理由は...」と言った場合
- ユーザーが「なぜ X を選んだのか？」と質問した場合（既存の ADR を読む）
- アーキテクチャ上のトレードオフが議論される計画フェーズ中
ADR Format
Michael Nygard が提唱した軽量 ADR フォーマットを、AI 支援開発向けに適応して使用します:
# ADR-NNNN: [Decision Title]
**Date**: YYYY-MM-DD
**Status**: proposed | accepted | deprecated | superseded by ADR-NNNN
**Deciders**: [who was involved]
## Context
この決定や変更を動機付けている問題は何か？
[状況、制約、作用している力を説明する2-5文]
## Decision
提案している、または実行している変更は何か？
[決定を明確に述べる1-3文]
## Alternatives Considered
### Alternative 1: [Name]
- **Pros**: [利点]
- **Cons**: [欠点]
- **Why not**: [却下された具体的な理由]
: [利点]
: [欠点]
: [却下された具体的な理由]
この変更により、何がやりやすくなり、何がやりにくくなるか？
[メリット 1]
[メリット 2]
[トレードオフ 1]
[トレードオフ 2]
[リスクと軽減策]
