review

レビュー

変更内容を各パスに照らしてレビューし、結果を総合して判定します。

参照されているスキルがローカルにない場合は、実行時に open-review リポジトリから取得してください。サブディレクトリを含むディレクトリ全体を取得します。npx が利用可能な場合は npx skills use elliottlawson/open-review@<name> を使用し、利用できない場合は GitHub からディレクトリを取得してください。

対象範囲

変更内容は、ベースブランチとのマージベースに対する差分です（git diff origin/main...HEAD、または呼び出し元が指定するベース／範囲）。参照が解決できることを確認してください。差分が空の場合は、その旨を伝えて終了してください。生成ファイルとベンダー提供ファイルは対象外です。

ステップ 0 — プロジェクトの参考資料を確認する

/infer-conventions を使用して、プロジェクトの規約と技術スタックを確認してください。読み込まれた内容は各パスで使用してください。プロジェクトに文書化された規約がない場合は、独自に作り上げず、その旨を判定に記載してください。

パス

次の順に実施します。ミッション → アーキテクチャ → 実装 → クラフト → セキュリティ → パフォーマンス。次に、結果を総合して判定します。

• 承認 — ミッションを達成しており、阻害要因となる指摘はありません。
• 要修正 — 実際の問題が見つかりました。内容を明記してください。
• 保留 — ミッションが不明確、またはアーキテクチャ上の懸念について、先に議論が必要です。

深さの調整。 対象範囲に応じて深さを調整してください。2 ファイルのバグ修正なら簡潔に、30 ファイルに及ぶ機能なら詳細にレビューします。

指摘する前に検証する。 指摘には、具体的な行と具体的な影響が必要です。検証できない場合は、質問として提示してください。

報告

指摘内容は文章で報告してください。深刻度（critical／warning／info）、検出したパス、ファイルと行番号、そして重要な理由を記載します。

• コードベースではなく変更を評価する。 阻害要因となる指摘は、新たに追加または実質的に変更されたコードに限ります。既存の違反は、あっても助言にとどめてください。
• 規約を引用し、目指すパターンを示す。 プロジェクトに文書化された規約がある場合は、指摘で違反している文書を挙げ、代わりに従うべきパターンを示してください。
• 繰り返し発生する問題は一度だけ報告する。 複数のファイルに同じ問題がある場合は、共通の指摘としてまとめ、その適用範囲を記してください。

CI 環境では、/review-as-json がこのレビューを JSON 形式でラップし、出力を整形します。