コードが動いても、終わりではない。正しく動いて初めて終わりだ。
AIは速く動く。速いとは、表面的には動くが、アーキテクチャから逸脱し、デザインシステムに違反し、重要なエッジケースを見逃すものが作られることを意味する。このスキルは、そうした問題が大きな問題に発展する前にキャッチする。
すべての機能開発の後に、次に進む前にこれを実行せよ。
このスキルがやらないこと
このスキルは何も修正しない。発見したことを報告し、開発者が何が重要でどう対処するかを決めるのを助ける。理解せずに修正することは、問題を解決するのではなく、埋もれさせるだけだからだ。
ステップ 1 — 何が作られるべきだったかを理解する
レビューを始める前に、基準を確立せよ。
以下の順序で読み込め：
/architectからの実装計画（存在する場合）- 与えられた機能説明またはタスク
- 関連するコンテキストファイル — アーキテクチャ境界、コード標準、設計ルール
計画が存在しない場合、レビューを始める前に開発者にその機能が何をすべきだったかを説明してもらえ。正しさが何かを知らなければ、正しさを検証することはできない。
ステップ 2 — 3つのレイヤーでレビューする
レイヤー 1 — 計画と一致しているか？
構築されたものを計画と比較せよ。
確認項目：
- 機能説明のすべての部分が実装されているか？
- 計画時に下された判断がコードに反映されているか？
- スコープ — 実装は範囲内に収まっているか、依頼されていないものを追加していないか？
計画されたのに欠落しているものにはフラグを立てよ。計画されていないのに実装されたものにもフラグを立てよ。
レイヤー 2 — システムを尊重しているか？
ここはAIのドリフトが最も頻繁に発生する場所である。機能は動くが、プロジェクトが依存するルールに違反している。
確認項目：
- アーキテクチャ境界 — コードは適切な場所で適切な責任を持っているか？APIルートにUIロジックはないか。コンポーネント内でDB呼び出しはないか。プロジェクトの境界が何であれ、それが尊重されているか？
- デザインシステム — 正しいトークン、クラス、パターンが使われているか？ハードコードされた値で変数にすべきものはないか？デザインシステムを使うべき生のカラークラスはないか？
- コード標準 — 命名規則、ファイル構成、TypeScriptの厳格さ、エラーハンドリングのパターン — これらはプロジェクトが確立したものに一致しているか？
- 既存のパターン — この機能は、既存のパターンを使うべきところに新しいパターンを持ち込んでいないか？
レイヤー 3 — 本番環境で使えるか？
確認項目：
- エラーハンドリング — 問題が発生したときどうなるか？エラーはキャッチされ処理されているか、それとも静かに失敗しているか？
- エッジケース — 空の状態、ローディング状態、データ欠落 — これらは処理されているか？
- コンソールエラー — ブラウザやターミナルにエラーや警告はないか？
- 明らかなバグ — 実際のユーザーにとって確実に壊れるものはないか？
ステップ 3 — 発見したことを報告する
3つのレイヤーすべてを完了したら、明確なレポートを作成せよ。問題を埋もれさせてはいけない。やわらかくしてはいけない。開発者が情報に基づいた決定を下せるよう、正直に報告せよ。
## レビュー — [機能名]
### レイヤー 1 — 計画との整合性
[合格 / 問題あり]
[計画と実装の間にあったギャップを列挙]
### レイヤー 2 — システムの整合性
[合格 / 問題あり]
[アーキテクチャ、デザイン、コード標準の違反を列挙]
### レイヤー 3 — 本番環境への readiness
[合格 / 問題あり]
[エラーハンドリングの欠落、エッジケース、明らかなバグを列挙]
### サマリー
[Y] レイヤーで [X] 件の問題を発見。
[問題がない場合: 「問題は見つかりませんでした。この機能は出荷準備完了です。」]
[問題がある場合: 「次の機能に進む前に、上記の問題を解決してください。」]
ステップ 4 — 開発者に判断を委ねる
レポートを提示したら、そこで止まれ。修正を始めてはいけない。開発者から依頼がない限り、修正案を提案してもいけない。
開発者が以下のいずれかを行うのを待て：
- 特定の問題の修正を依頼する
- 問題が意図的であり無視してよいと伝える
- すべて解決され、次に進む準備ができたと確認する
品質判断の決定権は開発者にある。あなたは情報を提供するだけだ。
重大度ガイド
すべての問題が同じ重みを持つわけではない。以下を使って開発者が優先順位をつけるのを助けよ：
Critical — 次に進む前に修正すべき
- 将来の機能を壊すアーキテクチャ境界違反
- サイレント障害を引き起こすエラーハンドリングの欠落
- 計画されていたが完全に欠落している機能
Important — 早急に修正すべき
- UIの一貫性を損なうデザインシステムの逸脱
- コードベース全体に影響が拡大するコード標準違反
- 実際のユーザーが遭遇するエッジケース
Minor — 都合の良いときに修正
- 動作に影響しない命名の不整合
- 最適化の欠落
- デザインシステムに影響しないスタイル上の問題
各問題にその重大度をラベル付けし、開発者が迅速にトリアージできるようにせよ。
基準
このスキルが答える問いは「動くか？」ではない。
問いは「正しいか？」である。
動くことと正しいことは同じではない。今日動く機能が、明日プロジェクトを壊すこともある。レビューはその違いを捉えるために存在する。