ADR-lite フォーマット
すべての判断はコンパクトな構造に従います：
| セクション | 説明 |
|---|---|
| コンテキスト | なぜこの判断が必要か |
| 判断 | 何が決まったか |
| なぜ | 最も強い理由1つ |
| 代わりに | 検討した代替案（最大3つ） |
| 結果 | 結果と影響範囲 |
複雑な判断には、拡張フォーマットで トレードオフ セクションが追加されます。
スマートな機能
代替案の自動推定
判断だけを書いた場合、AI が1-2の典型的な代替案を推定します：
/note-decide user サービスには PostgreSQL を使うAI が追加：代わりに MongoDB、MySQL — データベース選定の典型的な代替案だからです。
判断のチェーン
システムは既存の判断メモを検索します。新しい判断が古いものを置き換える場合、「Supersedes」 リンクを作成します：
Supersedes: 「user サービスには MongoDB を使う」（2月10日）これで遡れる判断の履歴が構築されます。
重複検出
新しいメモを作成する前に、/note-decide は関連する過去の判断を検索し、類似の判断が既に存在する場合に警告します。
タイトルのガイドライン
良いタイトルは実行可能で具体的です：
- 「Auth には JWT を使う」（「認証」ではなく）
- 「Fly.io にデプロイ」（「デプロイ」ではなく）
- 「REST から GraphQL に切り替え」（「API」ではなく）
/note-decide を使うべきとき
これは、何を選んだかだけでなく、なぜ選んだかを記録したいときに使ってください。判断ログは以下の場面で計り知れない価値があります：
- 新しいチームメンバーが「なぜこうやってるの？」と聞いたとき
- 数か月後に判断を見直す必要があるとき
- アーキテクチャがどう進化したかを追跡したいとき