PR・コミット・差分・ファイルをレビューし、再現条件と根拠のある不具合、回帰、検証漏れを報告する。変更が差分の外で何を壊しうるか（影響範囲）を、安全の根拠をコードで証明して確かめるときにも使う。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
変更差分をレビューし、不具合だけでなく契約、副作用、テスト戦略、アーキテクチャ整合まで評価する。良い点の称賛より、出荷を止めうる論点の抽出を優先する。
詳細な観点は必要に応じて読む。
references/review-rubric.mdreferences/severity-criteria.mdreferences/architecture-checklist.mdreferences/output-template.mdreferences/blast-radius.mdPR、コミット、差分、または対象ファイル。必要なら背景仕様、設計メモ、関連Issue。対象が明示されていても差分だけで閉じず、呼び出し元、呼ばれる側、既存テスト、関連設定、実運用の経路まで読む。
次の観点を変更に照らして検討し、影響がある経路を掘り下げる。観点ごとに全リポジトリを調べたり独立した節を作ったりする必要はない。
何が壊れるか、なぜこの変更で起きるか、どの経路で露見するかを具体的に説明できるものを指摘とし、references/severity-criteria.mdで重大度を付けて全て報告する。重大度による取捨選択は読み手が行うので、こちらで保守的に絞らない。
好みのスタイル論、根拠のない不安、契約を満たしている別案の提示だけのものは指摘にしない。アーキテクチャ上の違和感は指摘未満でもArchitecture notesに残す。
見落としやすい点:
ctx7）で現在の仕様を確認してから書く「何が壊れうるか」「影響範囲を見て」と頼まれたとき、または小さく見えるが危険がありそうな差分では、references/blast-radius.mdの手順で、変更の安全性が依存する1つの事実を見つけ、到達した確からしさの段階と証明を示す。証明できなければ「未証明」と書く。
references/output-template.mdに沿って、指摘、影響範囲（手順を使った場合）、判断に必要な補足、確認範囲の順に書く。該当しない節を埋めるために論点を作らない。指摘がなければその旨と確認範囲を示し、判断に影響する未検証の経路やレビューの限界を明示する。
PRやファイルのレビューでは、同じ内容を.tmp/research/YYYYMMDD_<topic>_review.mdにも保存する。
日本語の回答では自然な日本語で書く。コード、API名、固有名詞、ファイルパスなど正確性に必要な英語はそのまま残し、一般語は日本語にする。重大度の記号、該当位置、具体的な失敗条件は保つ。
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Codex CLI（`codex exec`）に、モデル・reasoning effort・速度を指定して作業（調査、レビュー、相談、実装）を頼み、結果を受け取って要約する。「solで〜して」「astra xhighで調べて」「luna low fastで」「Codexで〜」「Codexに聞いて／やらせて」のように、呼び名（sol / astra / luna）やCodexを指定して作業を頼まれたときだけ使う。文中に普通の単語として「sol」「luna」が出てきただけのときは使わない。
エージェントが同じ間違いを繰り返すとき、履歴から間違いの種類を洗い出し、設計、型、lint・CI、テスト、文書の順に、効く範囲で最も上の層で再発を防ぐ。計画を承認してから実装し、各チェックが過去の実際の間違いで失敗することを証明する。'/correct'で使う。
アプリを利用者と同じ操作で動かして振る舞いを確かめる、プロジェクト専用の検証スキル（`.claude/skills/verify-<app>/`）と機能一覧を作る。言語、フレームワーク、Web・CLI・API・デスクトップを問わない。'/create-verification-skill'、'このリポジトリの検証スキルを作って'、UI・CLI・サービスの振る舞いを確かめる手順がリポジトリにないときに使う。
リポジトリにエージェント開発用の検証基盤を整える。`make check`、GitHub ActionsのCI、短いAGENTS.mdを、言語とツールを検出して作る。'harness-init'、'リポジトリを初期化して'、'検証コマンドを用意して'、新規リポジトリ作成直後や既存リポジトリへの導入時に使う。
既存のコードやシステムが今どう動いているか（仕組み、処理の流れ、どこに何があるか、どの層やモジュールが持つべきか）を、コードを読んで説明する。'どうなっているか'、'仕組みを教えて'、'この処理の流れ'、'これはどこに置くべきか'、変更の前に既存の仕組みを理解したいときに使う。なぜ今の形なのか（経緯）は`why`、技術の選定は`research`を使う。
知らない分野にキャッチアップするとき、汎用的な言葉から界隈の用語・中心の人・場（学会・雑誌・個人ブログ・動画・リポジトリ・一覧）を特定し、 引用・リンク・著者を芋づる式にたどって、当たりの原文（論文も個人の記事や動画の字幕も）を要約せずそのまま ~/research/<話題>/sources/ に落とす。 周ごとに地図（map.md）を育て、要る主張の全部に原文が付くか飽和したら止める。 見張りのモードでは、地図の場（Qiita・Zenn のタグ、note、YouTube、ブログ、arXiv）の新着を RSS で引いて原文の冒頭つきで並べる。 以下で使用:「芋づる式に調べて」「この分野をキャッチアップしたい」「界隈の用語と人から掘って」 「論文とか先行研究を漁って」「既存の技術を真似したいから元ネタを探して」「上手い人のやり方を集めて」「原文で落として」「/imozuru」 「〇〇って研究あるの？原典ほしい」「全然わからないから流れを掘って」「どういう界隈でどう呼ばれてるか知りたい」 「〇〇の新着見て」「今週の〇〇の記事まとめて」「キャッチアップ」「/imozuru watch」 "dig into this field", "find the canonical papers on X", "literature dive", "what's new in X this week"。 以下には使用しない: 答えが1つの事実の確認（年・有無だけ・仕様1つ → そのまま検索）／ 手元の PC の中の資料を探す／読んだ資料の要約や解説を書く。