/da-design-review — 安いうちに捕まえる

差分ができた時点で、移行戦略・契約の形・デプロイ順といった高くつく判断は済んでおり、コードレビューはそれを問えない。このスキルはその判断そのものをレビューする。

このスキルは読み取り専用で、コードも計画も書き換えない。 所見を報告するだけ。計画の修正は別の行為として行う。

実行条件

ワークフロー上の位置

読むファイル

常に読む

条件つきで読む

「念のため」全部読むのは禁止。

Step 0. 対象を見つけ、それを検査するものを実行する

${CLAUDE_SKILL_DIR}/reference/spec-system.md に従う。openspec のリポジトリでは、対象は change ディレクトリ全体（proposal・design・tasks と spec delta）であり、1 ファイルではない。基準にはプロファイルが指定する rules ファイルも含む。

判断を下す前に spec_system.validate を実行し、出力をそのまま貼る。 形式の壊れた delta は設計の所見ではないので、所見として報告しない。機械的に確かめられる妥当性を確かめずに語らない。

強制するのは frontmatter の allowlist（文章は依頼にすぎない）。allowlist が許さない validator は実行不能として報告し、回避しない。 実行するのはプロファイルの validate argv だけ。シェルで始まるものや -c を含むものは拒否し、先に forbidden と照合する。それ以外は読み取りだけ。

Step 1. 計画を自分の言葉で言い直す

批判の前に、計画が何をするかを 3〜5 文で書く。何が変わり、なぜ、どの順で。

これをユーザーに見せる。 読み違いを最も安く捕まえられる場所。言い直せないほど曖昧なら、それ自体が最初の所見なので、止まって報告する。

Step 2. 計画を実際のコードで裏付ける

価値は、計画の前提とコードの実際のずれにある。

計画を支える主張（「このテーブルは追記のみ」「他の呼び出し元は依存していない」「フロントエンドはフィールド欠落を処理済み」）ごとに、コードを開いて確かめ、file:line を引く。確かめられない主張は脚注ではなく所見にする。

予算は 25 ファイル。達したら止まり、確かめなかったものを記録する（際限のない調査はレビューに要るコンテキストを食う）。

Step 3. 観点ごとにレビューする

${CLAUDE_SKILL_DIR}/reference/design-checklist.md を読み、順に進める。

大きな計画では、観点グループごとに parallel subagents を 1 メッセージでディスパッチする。各サブエージェントには計画、Step 2 の所見、finding-discipline.md を渡す（チェックリストとコード抜粋は大きく、抱えると統合を圧迫する）。小さな計画（数ファイルで不可逆なものが無い）は自分で直接進める。

Step 4. 一段上の問い

チェックリストとは別に、必ず問う。

• そもそも作るべきか。 価値の大半を得られる、より単純な方法はないか
• 計画は述べられた問題を解いているか。 近くの面白い問題を解いていないか
• 計画は何が成り立ち続けると仮定しているか。 仮定を挙げ、計画を支えるものに印をつける
• 丸ごと欠けているものは何か。 ロールバック経路、既存データの移行、デプロイ中の処理中リクエストの扱い、うまくいったと分かる運用上のシグナル

チェックリストは書かれたものの誤りを見つけ、このステップだけが書かれなかったものを見つける。

事前の検死 — 過去形で書く。時制が要点

頭で考えるだけでなく実際に書き出す。

今は 6 か月後。これは出荷され、失敗した。 障害の振り返りを書く。何が壊れたか、最初の症状は何か、誰かが気づくまでどれだけかかったか、振り返りで「明らかだったはず」とされたことは何か。

時制は文体の問題ではない。 根拠と出典は design-checklist.md の「事前の検死（Pre-mortem）」にある。

物語として書き、最初の症状は具体的にする。「キューが詰まり、1 日誰も気づかなかった」 は所見、「性能問題があるかもしれない」 は所見ではない。

その後、各原因を 🔴（計画が扱うべき）、🧭（形が間違っているかもしれない）、❓（計画が触れていない）に変換する。変換できない原因は、名前をつけた残存リスクとして報告に残す。 バケットに合わないという理由で落とさない。

Step 5. 自分の所見を反証する

必須。対象は 🚪 一方通行の判断と 🔴 の所見。 全体の形は ${CLAUDE_SKILL_DIR}/reference/verification.md を読む。既定で反証する非対称性、⛔/🔴 の 3 レンズ、処置の表はそのまま適用する。Step 1〜4 に関わっていない x-review-verifier にディスパッチする。

計画は文書なので、書かれていないものはすべて欠けて見える。 発見フェーズは構造的に欠落を過剰に報告するので、次の 3 問で戻す。

• その「一方通行の判断」は本当に不可逆か、戻すのが高いだけか。 高いだけなら 🟡。一方通行は、戻すとデータが失われる・管理外の利用者が壊れる・戻せない、のどれかの時だけ。閉じる瞬間を名指しできないなら一方通行ではない
• その欠落は本当に欠落しているか。 計画の他の箇所、既存の規約、フレームワークの既定を確かめる。最も多い誤検知は「ロールバックに触れていない」で、デプロイパイプラインが既にロールバックするなら反証される
• 設計が失敗する経路を書けるか。 具体的な悪い結果の無い「形が違う」は 🔴 ではなく 🧭。🧭 は残すが、🔴 の重大度を着せない

反証した件数を報告する。何も反証されなかったなら、このステップを実行していないか思いついたことを全部報告している。 どちらかを 🔎 に書く。

Step 6. 報告

バケット分けと見せ方は ${CLAUDE_SKILL_DIR}/reference/report-format.md に従い、次を置き換える。

必須の 4 部分は計画として読み替えて適用する。 report-format.md の設計レビュー向けの置き換え（Design review substitutions）に、⛔ → 🚪 の対応と 📍 が計画の節を指す方法とともにある。アーキテクチャ、集約とトランザクションの境界、セキュリティは、コードレビューより重く見る。 計画段階なら動かすのは安いが、後では書き直しになる。3 つのどれかに計画が触れていなければ、合格ではなく ❓。

骨格の全体は design-checklist.md の「報告の骨格」にあり、そのとおりに書く（不可逆な判断を直せるものより上に置く順）。次の 2 節は落とせないのでここにも載せる。

### 🚪 一方通行の判断（One-way doors）
| 判断 | どこから戻せなくなるか | 戻せない理由 | 進める前に成り立っているべきこと |

### 🧱 Landing plan（着地の分け方）
| # | 着地するもの（What lands） | 確認の関門（What gates it） | 一方通行？（One-way?） | 次を始める前に |

着地計画は同じ判断を書き出したもの

着地の分け目は、不可逆性とデプロイ順の判断の結論であり、他のどこもこれを決めない（da-fix-plan は change 内のコミット順、da-review-all は層を一緒に出すかを所見として問うだけ）。

N 行は N 個の change（openspec なら changes/<id>/ が N 個、それ以外は計画ファイルが N 個）。着地をタスクグループにした 1 つの change ではない（着地は単独で出荷され、タスクはされない）。この対応は da-spec が使うので spec-system.md にある。

規則は ${CLAUDE_SKILL_DIR}/reference/design-checklist.md の 着地の境界 にある。最も効く規則は どの着地にも名指しできる関門が要る こと。何がそれを証明するか言えないなら、計画は未完成。着地が 1 つなら、理由をつけた 1 行で正当な答えになる。表が無いのは誰も決めていないということ。

完了条件

• 批判の前に計画を言い直し、確認した
• 計画を支える主張はすべて、file:line で裏付けたか、未確認として挙げた
• 一方通行の判断を通常の所見と分けた
• Step 4 を実行した（誤りだけでなく欠落も見た）
• Step 5 を x-review-verifier で実行し、すべての 🚪 が閉じる瞬間を名指ししている
• いくつかの所見が退けられ、その件数を報告した。ゼロなら理由を 🔎 に書いた

次に

🔴 の項目に沿って計画を直す。形が大きく変わったなら /da-design-review をもう一度。そうでなければ実装へ進む。