review

レビュー

プロジェクトの原則に基づいた、徹底的で対話的なレビューです。変更は加えないでください。レビューそのものが成果物です。

自律セッションモード

このスキルが対話型ではない Noodle 実行セッション（たとえば Cook、Oops、Repair）で実行される場合：

• AskUserQuestion を使用しないでください。 見つかった問題ごとに選択肢を提示するのではなく、推奨する対応を直接記述してください。
• セッションの出力に加えて、brain/audits/review-<date>-<subject>.md にレポートファイルを作成してください。
• 重大度の高い問題については、/todo スキルを使用して brain/todos.md に TODO を登録してください。
• 重大度の低い問題はレポートに記載し、個別の TODO は登録しないでください。
• 最後に、レビュー報告書をコミットしてください。指示を待たないでください。

タスクを使って進捗を追跡してください。 以下の各ステップに対してタスクを作成し（TaskCreate）、開始時に in_progress、完了時に completed に更新してください（TaskUpdate）。各ステップの後に TaskList を確認してください。

ステップ 1 — 原則の読み込み

brain/principles.md を読みます。すべての [[wikilink]] をたどり、リンク先の原則ファイルをそれぞれ読んでください。これらの原則はレビューの判断基準です。問題を評価する際には、原則に立ち返ってください。

省略しないでください。原則の内容を記憶だけで済ませないでください。必ずあらためて読み込んでください。

ステップ 2 — 対象範囲の特定

コンテキストからレビュー対象を推定してください。ユーザーのメッセージ、最近の差分、参照されている計画や PR などを確認します。本当に推定できるものがない場合に限り、質問してください。

変更規模からレビューのモードを自動判定します：

• 大規模な変更（変更行数が 50 行以上、ファイル数が 3 以上、または新しいアーキテクチャ）— すべてのセクションを確認し、各セクションの主要な問題は最大 4 件
• 小規模な変更（上記のしきい値未満）— 各セクションにつき問題を 1 件

ステップ 3 — コンテキストの収集

小規模な変更のレビューでは、数ファイルを読むコストより委任のオーバーヘッドのほうが大きいため、メインコンテキスト内でファイルを直接読んでください。大規模な変更のレビューでは、Task ツールを使って探索をサブエージェントに委任してください。

次の作業を行う探索エージェント（subagent_type: Explore）を起動してください：

• レビュー対象のコードまたは計画を読む
• 依存関係、呼び出し元、下流への影響を特定する
• 関連する型、テスト、インフラストラクチャを把握する

互いに独立した領域を調査する場合は、複数のエージェントを並行して実行してください。

ステップ 4 — ドメインスキルの収集

インストール済みスキル（.claude/skills/）を確認し、レビュー対象のドメインに該当するものがないか探してください。よくある該当例：

ドメイン	スキル	適用対象
フロントエンド UI	frontend-design	Web UI コンポーネント、レイアウト、ビジュアルデザイン
Codex への委任	codex	Codex ワーカーに委任するタスク

上記に記載されていないドメインについては、find-skills を使って関連スキルを検索してください。

該当するスキルを今すぐ呼び出し、出力を読み、ドメイン固有のガイダンスをレビューに反映してください。

ステップ 5 — レビュー項目

すべての項目を確認してから、レビュー全体を提示してください。必要であれば、ユーザーは途中で方向性を変更できます。

1. アーキテクチャ

• システム設計とコンポーネントの境界
• 依存関係グラフと結合度
• データフローパターンとボトルネック
• スケーリング特性と単一障害点
• セキュリティアーキテクチャ（認証、データアクセス、API 境界）

2. コード品質

• コードの整理とモジュール構成
• DRY 違反 — 厳しく確認してください
• エラーハンドリングのパターンと不足しているエッジケース（明示的に指摘してください）
• 技術的負債の集中箇所
• 基礎的思考の原則に照らした、過剰設計または過少設計。第一原理からの再設計も検討してください

3. テスト

• カバレッジの不足（ユニット、統合、E2E）
• テストの品質とアサーションの強さ
• エッジケースのカバレッジ不足 — 徹底的に確認してください
• 未テストの障害モードとエラーパス

4. パフォーマンス

• N+1 クエリとデータベースアクセスパターン
• メモリ使用量に関する懸念
• キャッシュの機会
• 低速または計算量の多いコードパス

ステップ 6 — 課題の形式

各課題に番号（1、2、3…）を付けてください。課題ごとに、次の内容を記載します。

• ファイル名と行番号を示し、問題を具体的に説明する
• 「何もしない」を妥当な選択肢として含め、アルファベット（A、B、C）を付けた選択肢を2～3個提示する
• 各選択肢について、実装にかかる労力、リスク、他のコードへの影響、保守の負担を示す
• 基礎的な思考原則に照らして、推奨する選択肢とその理由を示す
• ユーザーに、同意するか、別の方向性を希望するかを尋ねる

AskUserQuestion を使用する場合は、各選択肢に課題番号と選択肢のアルファベットを付けてください。推奨する選択肢は常に最初に記載します。

対話ルール

• 期間や規模に関する優先事項を決めつけないでください
• 変更は行わず、調査結果を提示して指示を待ってください
• すべてのセクションをまとめて提示し、最後に一度だけフィードバックを求めてください
• 「動作を証明する」という原則に従い、テスト可能なことがあれば、その方法を課題の説明に記載してください