evaluate-adr
ユーザーから渡されたプロンプトを評価し、ADR（Architecture Decision Record）として記録すべき「意思決定」が含まれているかを判断する。create-adr スキルの Step 0 から内部的にコールされる。
評価基準
ADR に適するケース（推奨）
以下のいずれかに該当する場合、ADR として記録する価値がある：
- dotfiles コンポーネント（tmux / fish / claude / ghostty / nvim）に関わる設計判断
- 複数の選択肢を比較・検討したうえでの意思決定が含まれる
- 「なぜその設計を選んだか」が将来の変更時に参照価値を持つ
- アーキテクチャ・構成の変更（ツールの追加・削除・統合など）
- コンポーネント間の依存・連携に関する決定
ADR に適さないケース（不要）
以下に該当する場合、ADR として記録する必要はない：
- タイポや軽微なバグ修正（設計判断を伴わない）
- 一時的な変更・実験（記録に残す価値がない）
- 既存の ADR の実装タスク（
adr-shipスキルが適切） - 単純な設定値の変更（設計の意図が変わらない）
docs/issues.mdに既に同一課題が記録されている
評価ステップ
Step E-1: 既存 issues.md との重複チェック
$PWD/docs/issues.md を Read して、同一または類似の課題が既に登録されていないか確認する。重複が見つかった場合は既存エントリを提示して処理を中断する。
Step E-2: 意思決定の有無を判断
ユーザーのプロンプトから以下を評価する：
- 変更の性質: バグ修正 / 設定変更 / 設計変更 / ツール選定 のどれか
- 選択肢の存在: 複数のアプローチが考えられるか
- 将来の参照価値: 「なぜこの設計か」が後で問われうるか
Step E-3: 判定と出力
以下の3段階で判定し、結果を明示する：
| 判定 | 意味 | 後続処理 |
|---|---|---|
| ADR 推奨 | 意思決定を記録する価値がある | create-adr の後続ステップへ進む |
| ADR 不要 | 設計判断を伴わない変更 | 理由と代替案を提示して処理を中断する |
| 要確認 | ADR にすべきか判断が難しい | AskUserQuestion でユーザーに意図を確認してから再判定する |
ADR 不要の場合の代替案提示例
- バグ修正 → 直接修正して commit する
- 既存 ADR の実装 →
adr-shipスキルを使う - 重複課題 → 既存 issues.md のエントリを提示する
要確認の場合の確認例
- 「この変更は設計判断（なぜこのツールを選ぶか）を伴いますか？それとも実装上の問題（バグ修正）ですか？」