菜单
PRのレビュー報告書を作成する。bugや脆弱性の調査だけでなく、exportされた対話コンテキスト・PR概要欄・実装されたコードの整合性を確認し、実装者の正気を疑う。 ユーザーが「PRのレビュー報告書を書いて」「対話コンテキストと共にコードレビューして」「このPRの正気を疑って」と言った時に使用する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
リポジトリのセキュリティ調査を領域ごとに進める。 調査対象リストと観点リストに基づき、未調査の領域を選んで調査し、レポートを出力する。 複数sessionにまたがる長期作業を想定し、現状を確認して続きの作業を行う。
対話コンテキストをexportする。 会話で共有された目的・意図・設計判断・制約条件を `.dev/contexts/` ディレクトリに書き出し、PRが存在する場合はPRコメントにも投稿する。次の作業者（レビュワー、別セッションのAI、バグハンティングのAIなど）に引き継ぐ。 ユーザーが「コンテキストを書き出して」「対話コンテキストをexport」「会話した内容を.devに保存して」と言った時に使用する。
対話コンテキストをimportする。 `.dev/contexts/` ディレクトリに保存された過去の対話コンテキストを読み込み、開発の継続やレビューに活用する。 ユーザーが「コンテキストを読み込んで」「対話コンテキストをimport」「.devのコンテキストを読んで」と言った時に使用する。
定石外発想で実装をシンプルにする。現状の発展型ではなく、実装の裏にある暗黙の前提条件を1つずつ外し、よりシンプルな別解がないか検討する。 ユーザーが「定石外発想で」「前提を疑って」「もっとシンプルにできないか」と言った時に使用する。
Codex CLIと相談するスキル。 ユーザーが「codexと相談して」「codexに聞いて」「codexにレビューしてもらって」と言った時に使用する。 現在の会話コンテキストに基づいてCodex CLIにプロンプトを送り、結果を要約して報告する。
Agentツール（subagent）と相談するスキル。 ユーザーが「subagentと相談して」「subagentに聞いて」「subagentにレビューしてもらって」と言った時に使用する。 現在の会話コンテキストに基づいてsubagentにプロンプトを送り、結果を要約して報告する。
| name | sanity-review |
| description | PRのレビュー報告書を作成する。bugや脆弱性の調査だけでなく、exportされた対話コンテキスト・PR概要欄・実装されたコードの整合性を確認し、実装者の正気を疑う。 ユーザーが「PRのレビュー報告書を書いて」「対話コンテキストと共にコードレビューして」「このPRの正気を疑って」と言った時に使用する。 |
| argument-hint | [PR-URL-or-number] |
feature/bugfix/refactoring PRをレビューし、レビュー報告書を作成する。 報告書はレビュアーがGitHubに貼ってレビュー完了を示すためのものであり、修正点がある場合はそれを説明するためのものでもある。
library-update-review skillの対象であり、このスキルの対象外引数でPR番号またはURLが指定されている場合はそのPRを対象とする。 指定がない場合は、現在のブランチに紐づくPRを自動検出する。
いずれの場合も、以下のコマンドでPR情報を取得する:
gh pr view {PR番号またはURL} --json number,title,body,url,author,comments,headRefName
自動検出の場合は {PR番号またはURL} を省略する。
PRが見つからない場合はユーザーに報告して終了する。
PRタイトル、PR番号、ブランチ名は報告書のヘッダーに使用する。Reviewed atには現在の日時（YYYY-MM-DD HH:mm:ss）を、Reviewerには自分のAgent名を記入する。
以下の情報を取得する:
gh pr view の commentsgh api repos/{owner}/{repo}/pulls/{number}/comments --paginategh api repos/{owner}/{repo}/pulls/{number}/reviews --paginategh pr diff {number}以下の順序で対話コンテキストを探す:
PRコメントの中に「対話コンテキスト」というタイトルを含むコメントがないか確認する。 見つかった場合はその内容を対話コンテキストとして使用する。
ブランチ名をサニタイズ（/ \ : * ? " < > | を - に置換）し、.dev/contexts/{サニタイズ済みブランチ名}.md を探す。
見つかった場合はReadツールで読み込む。
AskUserQuestionツールで以下を確認する:
この手順はコードを読む前に行う。 コードの整合性確認に引っ張られて概要欄の構造的問題を見落とすことを防ぐため。
実装者は正気ではないかもしれない。よくわからずにPR概要欄を書いたり、AIに生成させてそのまま貼っているかもしれない。 この手順では概要欄だけを読み、レビュアーがこの概要欄を読んで「変更の妥当性を判断できるか」を評価する。
以下の4項目を 必ず全て 評価し、結果をメモする。全項目を評価してから次の手順に進む:
手順3・手順4・手順5と手順6の6-6では外部Agentにセカンドオピニオンを求める（ただし手順4の「長期視点で命名・設計を考察する」サブセクションは対象外）。手順6のうち6-1〜6-5は疑わしい点がある場合に限り外部Agentへ相談する。以下のフォールバック順序に従い、推測で判断せず実際に呼び出して試すこと:
自分自身がCodex CLIの場合は2から開始する。そうでない場合は1から開始する。
codex-consultation を呼び出す。失敗した場合は2へ進むsubagent-consultation を呼び出す。失敗した場合は3へ進むフォールバックが発生した場合や、外部Agentが利用できなかった場合は、報告書の「レビュー作業において発生した問題」セクションに記載する。
3（main agent単独実行）にフォールバックした場合は、このスキルのコアである批判的思考の連鎖（互いの主張を検討・反論しあい、正確性と網羅性を向上するプロトコル）が機能していないことを意味する。往復検証が欠落した状態でのレビューは本来の精度を持たないため、報告書の「レビュー作業において発生した問題」セクション冒頭に、以下の文言をそのままbold段落として記載すること:
⚠ 警告: 批判的思考の連鎖が機能していません、実行環境が正気である事を疑ってください
各手順では、外部Agentに渡すArgsの内容と、結果の扱い方を記載する。
この手順の目的は、概要欄やコメントでの説明と実際のコードが一致しているかを確認する、ドキュメントとコードの読み合わせ である。
PR概要欄の author と、各コメントの author を照合し、実装者本人の発言のみを実装の説明として扱う。 他の人が書いた応援コメント、機能に対する期待を込めたコメント、質問等は、実装の説明ではない。 これらを実装の説明と混同すると、整合性の判断を誤る。
齟齬を発見した場合は具体的に記録する。
Agent自身の確認に加えて、外部Agentにも差分と概要欄の整合性を確認させる。 別の視点でコードを読むため、Agentが見落とした齟齬を発見できる可能性がある。
「外部Agent相談の共通方針」に従い、以下のArgsで呼び出す:
Args: よく相談して。PR #{番号} の概要欄の説明と実際の差分に齟齬がないか確認してほしい。{概要欄の要約と確認ポイント}
外部Agentの指摘を受け取ったら、自分の確認結果と照合し、見落としがなかったか確認する。
この手順の目的は、実装が既存のコードベースの慣習と一致しているかを確認する、コードベースの読み解き である。 バグ・脆弱性を調べる前にコードベースを理解することで、後続の調査の精度が上がる。
命名規則の一致
設計パターンの一致
齟齬を発見した場合は具体的に記録する。
Agent自身の確認に加えて、外部Agentにも命名・設計パターンの一貫性を確認させる。
「外部Agent相談の共通方針」に従い、以下のArgsで呼び出す:
Args: よく相談して。PR #{番号} で追加・変更された命名と設計パターンが、既存のコードベースの慣習と一致しているか確認してほしい。{変更概要}
外部Agentの指摘を受け取ったら、自分の確認結果と照合し、見落としがなかったか確認する。
将来、コードベースが拡張されたときに、現在の命名・設計が禍根となりうるかを考察する。 既存コードとの一致（事実判定）とは異なり、これは議論のタネを提供して人間の想像力を掻き立てるための作業である。
気になった点があれば、「懸念・反証・結論または保留」を押さえた自問自答形式で書き出す。 これはAgent自身の見解なので、通常の段落として記載する。1論点につき2〜3段落程度でよい。 無理に結論を出さなくてよい。気になる点がなければ「特になし」と記載する。 この考察セクションは外部Agentには振らず、skill実行元のAgentが自分で考える。
出力例:
「access-token」という名前は、現状はユーザーとサービス間のtokenしか指さないため問題はない。
ただ今後、外部サービスとの接続用のtokenが登場した場合は、概念衝突が起きる可能性がある。
そうなったら `user-access-token` のように主体を名前に含める必要が出るかもしれない。
もっとも、現時点で外部サービス連携を近い将来に追加する計画は見えていないため、今すぐ修正すべき問題ではないと判断する。
「member-metrics」という名前についても、将来 project member 以外の member 概念が増えた場合には曖昧になる余地がある。
一方で既存コードでは `Member` は project member を指す語として定着しており、短期的には大きな問題はなさそうである。
したがって現時点では問題なしと判断する。
ただし、将来 organization member など別種の member 概念を導入するなら、命名の見直しは必要になる。
「外部Agent相談の共通方針」に従い、外部Agentにコードレビューを依頼する。 引数には、PRの変更概要、差分の要約、確認してほしいポイントを含める。
深さの指定を引数に含めること。consultation系スキルは深さが未指定だとユーザーに聞き返すため、レビューの流れが中断される:
Args: よく相談して。PR #{番号} のコードレビューをお願いします。{変更概要と確認ポイント}
外部Agentの指摘を鵜呑みにしない。以下を行う:
対話コンテキストがない場合はこの手順をスキップする。
コードレビューは作業結果のダブルチェックではない。結果ではなくプロセスをレビューする。
やった事はコードを読めばわかる。検討した上でやらなかった事こそ、設計のレビューに必要な情報である。 対話コンテキストに書かれた設計判断・却下理由・意図的な非対応の「プロセス」が正しいかを検証する。
対話コンテキストを改めて精読し、以下を検証する:
対話コンテキストに書かれた設計判断の理由が、コードの実態と一致しているか。
対話コンテキストの「却下した代替案」セクションから、各代替案を1つずつ抜き出して再評価する:
「試したがダメだった」と記載されているものについて、結果だけでなく試し方自体を疑う:
「やらない」と決めたものについて:
対話コンテキストに書かれた「事実」が本当に正しいか、コードを読んで検証する。
疑わしい点がある場合は、「外部Agent相談の共通方針」に従い外部Agentにも相談する。Argsに「よく相談して」を含めること。
この手順が狙うのは「定石外発想」── 現状の発展型（既存案に機能や記述を足す方向）ではなく、前提という枷を外したときに立ち現れる解 ── である。
6-2・6-3が却下案・失敗試行（過去に捨てた選択肢）の判断の公平さを検証するのに対し、ここでは採用された設計そのものが置いている前提を組み替えられないかを検証する。
対話コンテキストやコードに根拠のない空想上の要件・前提は持ち込まず、レビュー対象の変更が依存している前提だけを扱う。
Agent自身の再評価に加えて、外部Agentにも前提解除を独立に行わせる。別の視点で前提を洗い出すことで、Agentが当然視して見落とした前提を拾える。外部Agentは放っておくと既存案のレビュー（現状の発展型）に流れるため、「レビュー」ではなく上記1〜4の手順そのもの（前提を自分で列挙し、1つずつ外してよりシンプルな解を探す）を実行させること。
「外部Agent相談の共通方針」に従い、以下のArgsで呼び出す:
Args: 軽く相談して。PR #{番号} の採用案が依存している前提を自分で列挙し、各前提を1つずつ外したらよりシンプルな解になるか検討してほしい（既存案のレビューではなく前提の組み替え）。対話コンテキストとコードに根拠のある前提だけを扱い、空想上の要件は持ち込まないこと。{採用案と対話コンテキストの要約}
外部Agentの別解を受け取ったら、自分の再評価と照合し、見落とした前提やより良い解がなかったか確認する。
このSKILL.mdと同じディレクトリにある TEMPLATE.md を読み込み、その形式に従って報告書を作成する。
報告書は会話に出力する（ファイルに保存しない）。 レビュアーが自分でGitHubにコピー＆ペーストする。