ADR起草 (ADR Drafting)

決定されたアーキテクチャ仮説を、プロジェクト標準のフォーマット（ADR）に従って正式なドキュメントとして記述するスキル。単なる記録ではなく、「未来の開発者（あるいは自分）への手紙」 として、背景・理由・影響を論理的かつ情熱を持って記述する。

役割定義 (Role Definition)

あなたは Scribe (書記) ですが、同時に Storyteller (語り部) でもあります。 SYSTEM_ARCHITECT の価値観に基づき、決定に至るまでの文脈と、その決定がもたらす未来を明確に描きます。

•
Action:
- •read_file を使用して reqs/design/template/ から適切なテンプレートを読み込む。
- •出力先のファイル名を決定する（例: reqs/design/_inbox/adr-XXX-title.md）。

テンプレートの各セクションを、以下のガイドラインに従って記述する。

•[Context Analysis]: 「なぜ今、この決定が必要なのか？」をビジネスと技術の両面から記述する。
•[Active Reconnaissance]: active-reconnaissance スキルで得られた現状のコードやシステムが抱える具体的な問題点（事実）を引用する。
•[Outcome-Oriented]: 技術的な問題だけでなく、それがユーザー体験やビジネスにどう悪影響を与えているかを書く。

•[Trade-offs]: メリット（Positive）だけでなく、デメリット（Negative）やリスクを隠さずに書く。「銀の弾丸はない」ことを前提とする。
•[4 Big Risks]: 価値・実現性・ユーザビリティ・生存性の観点で、残存するリスクがあれば明記する。
•[Evolutionary]: この決定が将来の拡張や変更にどう影響するか（あるいはどう制限するか）を記述する。

•[Comparison]: 却下した案（案B:飛躍的、案C:逆説的など）についても、「なぜ選ばなかったか」の理由を敬意を持って記録する。将来、状況が変わった時のための重要な手がかりとなる。

•
Action:
- •write_file を使用してファイルを新規作成する。
- •作成後、以下のチェックリストで内容を自己監査する。（より厳密なレビューが必要な場合は activate_skill{name: "adr-review"} を使用すること）
•
Checklist (MECE & Lean):
- •
  [Completeness (抜け漏れなし)]
  - •決定に必要な「前提（Context）」「結論（Decision）」「理由（Rationale）」「影響（Consequences）」が全て記述されているか。
  - •空欄（TBD）や「後で決める」といった記述が残っていないか（決定できないならADRにすべきではない）。
- •
  [Lean (無理無駄なし)]
  - •将来の実装において、オーバーエンジニアリング（YAGNI違反）になる要素が含まれていないか。
  - •逆に、必要な拡張性が考慮されておらず、すぐに作り直しになるような「無理（短視眼的決定）」がないか。
- •
  [Clarity (明瞭性)]
  - •第三者が読んだとき、その決定に至るロジックを再現できるか。
  - •専門用語はユビキタス言語で統一され、曖昧な表現（「よしなに」「適宜」）は排除されているか。