From sanity-review
Generates PR review reports verifying consistency between PR descriptions, comments, conversation contexts, and code changes. Checks bugs, vulnerabilities, and implementer sanity.
npx claudepluginhub shokai/agent-skills --plugin sanity-reviewThis skill uses the workspace's default tool permissions.
feature/bugfix/refactoring PRをレビューし、レビュー報告書を作成する。
Reviews GitHub PR comments by verifying against current code, categorizes issues, replies with reasoning, implements fixes, and resolves threads in one pass.
Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.
Share bugs, ideas, or general feedback.
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では外部Agentにセカンドオピニオンを求める。以下のフォールバック順序に従い、推測で判断せず実際に呼び出して試すこと:
自分自身がCodex CLIの場合は2から開始する。そうでない場合は1から開始する。
codex-consultation を呼び出す。失敗した場合は2へ進むsubagent-consultation を呼び出す。失敗した場合は3へ進むフォールバックが発生した場合や、外部Agentが利用できなかった場合は、報告書の「レビュー作業において発生した問題」セクションに記載する。
各手順では、外部Agentに渡すArgsの内容と、結果の扱い方を記載する。
この手順の目的は、概要欄やコメントでの説明と実際のコードが一致しているかを確認する、ドキュメントとコードの読み合わせ である。
PR概要欄の author と、各コメントの author を照合し、実装者本人の発言のみを実装の説明として扱う。 他の人が書いた応援コメント、機能に対する期待を込めたコメント、質問等は、実装の説明ではない。 これらを実装の説明と混同すると、整合性の判断を誤る。
齟齬を発見した場合は具体的に記録する。
Agent自身の確認に加えて、外部Agentにも差分と概要欄の整合性を確認させる。 別の視点でコードを読むため、Agentが見落とした齟齬を発見できる可能性がある。
「外部Agent相談の共通方針」に従い、以下のArgsで呼び出す:
Args: 普通に相談して。PR #{番号} の概要欄の説明と実際の差分に齟齬がないか確認してほしい。{概要欄の要約と確認ポイント}
外部Agentの指摘を受け取ったら、自分の確認結果と照合し、見落としがなかったか確認する。
「外部Agent相談の共通方針」に従い、外部Agentにコードレビューを依頼する。 引数には、PRの変更概要、差分の要約、確認してほしいポイントを含める。
深さの指定を引数に含めること。consultation系スキルは深さが未指定だとユーザーに聞き返すため、レビューの流れが中断される:
Args: よく相談して。PR #{番号} のコードレビューをお願いします。{変更概要と確認ポイント}
外部Agentの指摘を鵜呑みにしない。以下を行う:
対話コンテキストがない場合はこの手順をスキップする。
コードレビューは作業結果のダブルチェックではない。結果ではなくプロセスをレビューする。
やった事はコードを読めばわかる。検討した上でやらなかった事こそ、設計のレビューに必要な情報である。 対話コンテキストに書かれた設計判断・却下理由・意図的な非対応の「プロセス」が正しいかを検証する。
対話コンテキストを改めて精読し、以下を検証する:
対話コンテキストに書かれた設計判断の理由が、コードの実態と一致しているか。
対話コンテキストの「却下した代替案」セクションから、各代替案を1つずつ抜き出して再評価する:
「試したがダメだった」と記載されているものについて、結果だけでなく試し方自体を疑う:
「やらない」と決めたものについて:
対話コンテキストに書かれた「事実」が本当に正しいか、コードを読んで検証する。
疑わしい点がある場合は、「外部Agent相談の共通方針」に従い外部Agentにも相談する。Argsに「よく相談して」を含めること。
このSKILL.mdと同じディレクトリにある TEMPLATE.md を読み込み、その形式に従って報告書を作成する。
報告書は会話に出力する（ファイルに保存しない）。 レビュアーが自分でGitHubにコピー＆ペーストする。