omc-review

レビュー

既存の成果物を評価する際に、このスキルを使用します。レビューでは、評価対象の変更を作成しません。

これが標準のレビュー手順です。ai-slop-cleaner は、その中のオプトイン方式のレーンです。

目標

実際の問題を深刻度順に特定し、対処できるだけの詳細を示します。

ワークフロー

1. 何が変更され、その変更が何を目的としていたかを確認します。
2. その意図に照らして変更内容を読みます。
3. まず正確性を確認し、次にリスク、最後に簡素化を確認します。
4. 報告する前に、候補となる指摘をそれぞれ検証します。
5. 深刻度の高い指摘から順に報告します。

確認項目

• 正確性 — ロジックの欠陥、エッジケース、エラー経路、並行処理
• リスク — セキュリティ境界、破壊的な操作、データの整合性
• 再利用 — 変更で使用すべき既存のユーティリティやパターン
• 簡素化 — 削除またはまとめられるコード
• テスト範囲 — テストされていないままリリースされる動作

2 つの軸で別々に実施

大規模な差分は、2 つの並行するサブエージェントによるレビューとして実施し、結果を別々に報告します。変更が一方の軸では合格し、もう一方では不合格になることもあるため、統合したり、軸をまたいで順位付けしたりしてはいけません（規約には準拠していても動作が誤っている場合や、意図には忠実でも慣例に反している場合があります）。

• 規約の軸 — リポジトリで文書化されている規約と、判断を要するものに限ったコードスメルの基準に照らして差分を確認します。ツールで既に強制されている項目は対象外です。規約は推測せず、リポジトリから特定します。規約文書（CLAUDE.md/AGENTS.md、docs/standards/ 内の各文書、CONTRIBUTING.md、CODING_STANDARDS.md など）を検索し、存在するものすべてを基準にレビューします。確認していない規約ファイルがあるなら、その規約は適用されていません。
• 意図の軸 — 作業の目的（タスク、仕様、チケットの受け入れ条件）に照らして差分を確認します。不足している要件や一部しか満たされていない要件、誰も求めていない動作を指摘し、各指摘には根拠となる記述の行を引用します。

各サブエージェントへの指示は約 400 語以内にまとめ、対象の軸だけに絞ります。結果を集約する際、どちらか一方を勝者として選んではいけません。軸を分けているのは、再順位付けを避けるためです。各軸の判定はそれぞれ独立して示します。差分が小さい場合は、1 回のレビューで十分です。

ルール

• レーンを分けます。レビュアーは、作成者と同じアクティブなコンテキストを使ってはいけません。
• 報告前に検証します。もっともらしく聞こえても再現しない指摘はノイズです。
• 深刻度は正直に示します。網羅的に見せるために指摘を水増ししてはいけません。
• 問題がないという結果も有効です。
• 原則として助言を目的とします。レビューは判断材料であり、承認の可否を決めるものではありません。リリース、セキュリティ、破壊的な操作に関する厳格なゲートは別に設け、フェイルクローズにします。

出力

• 深刻度の高い順に、ファイル、行番号、具体的な失敗シナリオを添えた指摘
• 確認して問題がなかった項目
• 評価できなかった項目