review

コードが実行できるだけでは、構築は完了ではありません。コードが正しいときに、初めて完了です。

AI の進化は速く、速さゆえに、表面的には動作していてもアーキテクチャから逸脱したり、デザインシステムに違反したり、重要なエッジケースを見落としたりするものが作られます。このスキルは、そうした問題が積み重なって大きな問題になる前に発見します。

機能を追加するたびに、次に進む前に実行してください。

このスキルで行わないこと

問題の修正は行いません。見つかった内容を報告し、何が重要で、どう対応するかは開発者に判断してもらいます。理解せずに修正すると、問題は解決されず、埋もれてしまいます。

---

ステップ 1 — 何を実装すべきだったかを把握する

何かをレビューする前に、基準を明確にします。

次の順に読みます。

• /architect の実装計画がある場合は、その計画
• 指定された機能の説明またはタスク
• 関連するコンテキストファイル（アーキテクチャの境界、コード規約、デザインルールなど）

計画がない場合は、レビューを始める前に、その機能がどのように動作する想定だったかを開発者に説明してもらいます。正しい状態を知らなければ、正しさを検証できません。

---

ステップ 2 — 3 つのレイヤーでレビューする

レイヤー 1 — 計画に沿っているか？

実装された内容を計画と照らし合わせます。

確認事項：

• 機能の説明にあるすべての項目が実装されていますか？
• 計画時に決めた内容がコードに反映されていますか？
• スコープは守られていますか？依頼されていないものが追加されていませんか？

計画されていたのに未実装の項目を指摘します。計画になかったのに実装された項目も指摘します。

レイヤー 2 — システムのルールに従っているか？

AI による逸脱が最もよく起こるのがこのレイヤーです。機能は動作していても、プロジェクトが依存するルールに違反していることがあります。

確認事項：

• アーキテクチャの境界 — 適切な場所にあるコードが、適切な責務を担っていますか？API ルートに UI ロジックがありませんか？コンポーネントに DB 呼び出しがありませんか？プロジェクトで定めた境界が守られていますか？
• デザインシステム — 適切なトークン、クラス、パターンが使われていますか？変数にすべき値がハードコードされていませんか？デザインシステムを使うべき箇所に、生の色クラスが使われていませんか？
• コード規約 — 命名規則、ファイル構成、TypeScript の厳格さ、エラー処理のパターンは、プロジェクトで定めたものと一致していますか？
• 既存のパターン — 既存のパターンを使うべきところに、新しいパターンが導入されていませんか？

レイヤー 3 — 本番環境に対応できる状態か？

確認事項：

• エラー処理 — 問題が発生した場合、どうなりますか？エラーは捕捉して処理されますか？それとも機能が何も表示せずに失敗しますか？
• エッジケース — 空の状態、読み込み中の状態、データがない場合は処理されていますか？
• コンソールエラー — ブラウザーやターミナルにエラーや警告はありませんか？
• 明らかなバグ — 実際のユーザーが使ったときに、明らかに動作しなくなる箇所はありませんか？

---

ステップ 3 — 見つかった内容を報告する

3 つのレイヤーすべてを確認したら、明確なレポートを作成します。問題を隠さず、表現を和らげず、開発者が情報に基づいて判断できるよう、率直に報告します。

## Review — [Feature Name]

### Layer 1 — Plan alignment
[PASS / ISSUES FOUND]
[List any gaps between what was planned and what was built]

### Layer 2 — System integrity
[PASS / ISSUES FOUND]
[List any architecture, design, or code standard violations]

### Layer 3 — Production readiness
[PASS / ISSUES FOUND]
[List any error handling gaps, edge cases, or obvious bugs]

### Summary
[X] issues found across [Y] layers.

[If no issues: "No issues found. This feature is ready to ship."]
[If issues: "Resolve the above before moving to the next feature."]

---

ステップ 4 — 開発者の判断を待つ

レポートを提示したら、そこで止めます。修正を始めてはいけません。開発者から求められない限り、修正方法も提案しません。

開発者から次のいずれかの指示があるまで待ちます。

• 特定の問題を修正するよう依頼される
• 問題は意図的なもので、無視してよいと伝えられる
• すべて解決済みで、次に進めると確認される

品質に関する判断は開発者が行います。あなたは判断に必要な情報を伝えます。

---

重大度ガイド

すべての問題が同じ重要度とは限りません。開発者が優先順位を付ける際に、次のガイドを参考にしてください。

重大 — 次に進む前に修正

• 今後の機能に支障をきたすアーキテクチャ境界の違反
• サイレント障害を引き起こすエラーハンドリングの欠如
• 計画されていたものの、まったく実装されていない機能

重要 — 早めに修正

• UI の一貫性を損なうデザインシステムからの逸脱
• コードベース全体に波及するコーディング規約の違反
• 実際のユーザーが遭遇するエッジケース

軽微 — 都合のよいときに修正

• 動作に影響しない命名の不一致
• 最適化の不足
• デザインシステムに影響しないスタイル上の問題

開発者がすばやく優先順位を判断できるよう、各問題に重大度を付けてください。

---

基準

このスキルが答えるのは、「動作するか？」ではありません。

「正しいか？」です。

動作することと正しいことは同じではありません。ある機能が今日動作していても、明日プロジェクトに支障をきたす可能性があります。レビューでは、その違いを見つけます。