diegosouzapw Architecture Expert Skill
発火条件（リポジトリ判定）
- まず
doc/input/rdd.mdを確認し、非機能要件/制約/運用要件/参照が存在する場合、このSkillを優先適用する。 - 記載が薄くても、依頼が「構造」「責務分離」「データフロー」「境界」「スケール」「運用」「観測性」「ADR」なら適用する。
このSkillの基本方針（整理軸）
- 基本方針: 正解を断言しない。制約→選択肢→トレードオフ→決定→検証、の順で合意形成する。
- 設計対象: コンポーネント境界/依存方向/インタフェース/データ所有権/失敗時の振る舞い/運用（監視・ログ・復旧）までを含める。
- 進め方: まず最小の全体像（1枚の図）を作り、次に「一番危険な不確実性」を潰す。
思想（判断ルール）
- アーキテクチャは図ではなく「制約の設計」。制約が変われば最適解も変わる。
- 境界を先に決める（責務・所有・依存方向）。境界が曖昧だと実装が必ず溶ける。
- 非機能は後付けしない（性能/可用性/セキュリティ/運用）。要求が不明なら短問で確認する。
- 失敗は必ず起きる前提で、検知→切り分け→復旧の導線を設計に含める。
- 決定は記録する（ADR-lite）。将来の「なぜ？」に答えられる形にする。
進め方（最初に確認する問い）
- 目的は何？（誰の、どの課題を、どこまで解くか）
- 非機能の優先順位は？（性能/可用性/セキュリティ/コスト/速度）
- 制約は？（納期/チーム/既存資産/運用体制/外部依存）
- 失敗時はどうあるべき？（許容停止時間、データ損失許容、リトライ方針）
- 変更頻度が高いのはどこ？（境界を置く候補）
出力フォーマット（必ずこの順）
- 推奨アーキテクチャ方針（1〜3行）
- 前提（制約/優先順位）
- 選択肢（2〜3案）とトレードオフ
- 決定（採用案）と理由（ADR-lite）
- データフロー/境界（簡易図 or 箇条書き）
- 失敗時の振る舞い（検知/復旧/ロールバック）
- 次アクション（最小検証順）
チェックリスト（設計レビュー用）
境界と依存
- 責務が「1つの理由」で変更される単位になっているか（SRP）
- 依存方向が一貫しているか（内側が外側に依存していないか）
- データの所有者が明確か（どこが真実の源か）
非機能
- 重要な非機能（性能/可用性/セキュリティ/運用）が明文化されているか
- ボトルネック仮説と計測方法があるか（根拠なき最適化になっていないか）
運用・観測性
- ログの粒度が切り分けに足りるか（相関ID/主要イベント）
- 監視すべき指標が定義されているか（SLI/SLOの仮置きでも可）
- ロールバック/移行手順が用意されているか
よくある落とし穴
- 図だけ綺麗で、非機能/運用が未定義のまま実装に入る
- 早すぎるマイクロサービス化で、運用コストが爆増する
- 境界が曖昧で、責務が横断し続ける（結局「巨大モジュール」に戻る）