| name | arch-review |
| description | アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。 |
| argument-hint | [設計書パス / ソースディレクトリ / スコープ。省略時は git diff 対象] |
| context | fork |
| agent | architecture-reviewer-agent |
設計・アーキテクチャの「質」をレビューしてください。見るのはマクロ構造と変更容易性だけです——文書品質・行レベルのコード品質・設計書↔コードの整合性には踏み込まないでください（それぞれ /doc-review・/code-review・/validate-design の責務）。
中核の問いは一つ：この設計は変更が容易か＝詳細（UI・DB・外部サービス・言語・FW）を境界の外に追い出し、差し替え可能に保てているか。 例えば UI を Web→モバイル/CLI に替えてもドメインは無傷か、DB を替えても影響は境界内に閉じるか、外部 SDK がドメインに直接食い込んでいないか、言語が不必要に分散していないか、を具体的に検査してください。あわせて新規開発では、まだ決めなくてよい詳細（DB 製品・外部サービス等）を早期に具体実装で固定せず、境界＋スタブ（固定値を返す仮実装）で決定を遅らせているかも見てください。ただし要件・組織標準で確定済みの詳細を無理に遅らせよと求めてはいけません（遅延もコスト）。
実装があるときは、構造を読んだ印象で採点せず変更プローブで裏を取ってください——公開識別子を隔離環境でリネームし、波及がどの層まで届くかを実測します。詳細な手順と判定は agent 定義の Phase 3 に従ってください。
各レビュー観点は対応する正典 policy（変更容易性→docs/policy/application-architecture-policy.md、依存→docs/policy/dependency-policy.md、定義→docs/policy/refined-engineer-judgment-principles.md 冒頭の定義）を必ず Read して照合してください。設計書があれば設計意図を、実装があればコード構造を、あるものを見て（アダプティブ）レビューしてください。
レビュー結果の起票
レビュー結果を出力したら、続けて gh issue create で GitHub Issue を起票してください。ユーザーへの確認は行いません（CLAUDE.md の boy-scout ルール）。指摘が1件も無ければ起票しません。
| 起票対象 | 粒度 | タイトル | なぜ |
|---|
| [Critical] | 1件ごとに1 Issue | [Critical] アーキテクチャ: <問題の概要> | 差し替え時に広く壊れる急所は、境界の引き直しごとに着手・クローズされる。束ねると一部だけ直った状態が残る |
| [Recommended] ＋ [Suggested] | 全件まとめて1 Issue | [推奨・提案] アーキテクチャレビュー指摘まとめ | 1件ずつ判断するほど重くない。件数分に割ると Critical の Issue が埋もれる |
タイトルの先頭ラベルは省略しないでください——本文を開かないと指摘の重さが分からない状態を避けるためです。
本文の書き方・ラベル・起票前セルフチェックは .claude/skills/quick-issue/SKILL.md が正典です。Read して従ってください。
Issue 本文の「現状」には、レビュー結果の箇所・理由・改善案を書き写してください（レビュー結果を読み返さずに着手できるように）。
引数: $ARGUMENTS
