メニュー
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/kasiopeiya/claude-dev-template --skill arch-reviewコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
docs/ 配下を横断的に走査し、文書間の重複（DRY違反）と矛盾を検出する。「doc-consistency」「ドキュメントの整合性を見て」と指示されたとき。単一文書の品質レビューは /doc-review。
SKILL.md を表示中
| 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