菜单
アプリの設計・アーキテクチャの「質」をレビューする。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命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 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