PRのレビュー報告書を作成する。bugや脆弱性の調査だけでなく、exportされた対話コンテキスト・PR概要欄・実装されたコードの整合性を確認し、実装者の正気を疑う。ユーザーが「PRのレビュー報告書を書いて」「対話コンテキストと共にコードレビューして」「このPRの正気を疑って」と言った時に使用する。
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
feature/bugfix/refactoring PRをレビューし、レビュー報告書を作成する。 通常のコードレビューを補助するだけでなく、実装者が自らPRをレビューするためのセルフレビューツールでもある。人間のレビュアーに見せられる正気なpull requestに仕上げる事を目的とする。
library-update-review skillの対象であり、このスキルの対象外まず実行環境を確認する。いずれかを満たさなければレビューを行わず、満たさない条件をユーザーに報告して停止する:
command -v codex を実行して有無を確認し、あれば短いプロンプトを作業ツリー外のファイルに書き、codex exec --ephemeral にstdinで渡して1回実行し、出力のヘッダから読む。Luna・Terra等の軽量tierと、Solより前の世代のmodelは相談相手として足りないcodex exec を直接実行するのはこの確認だけにする。以降の手順でCodexに相談する時は、必ず「外部Agent相談の共通方針」に従い、Skill toolで codex-consultation を呼び出す。Codexの実行環境の取得と相談の往復は、codex-consultationが担う。
引数で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名とmodel名を記入し、外部Agentを使った場合はconsultation skillが取得した実行環境を併記する。
以下の情報を取得する:
gh pr view の commentsgh api repos/{owner}/{repo}/pulls/{number}/comments --paginategh api repos/{owner}/{repo}/pulls/{number}/reviews --paginategh pr diff {number}レビュー作業を始める前に、AskUserQuestionツールで報告書の出力先を確認する:
ユーザーが明示的に出力先を指定している場合はこの確認を省略し、指定に従う。
以下の順序で対話コンテキストを探す:
PRコメントの中に「対話コンテキスト」というタイトルを含むコメントがないか確認する。 見つかった場合はその内容を対話コンテキストとして使用する。
ブランチ名をサニタイズ（/ \ : * ? " < > | を - に置換）し、.dev/contexts/{サニタイズ済みブランチ名}.md を探す。
見つかった場合はReadツールで読み込む。
AskUserQuestionツールで以下を確認する:
この手順はコードを読む前に行う。 コードの整合性確認に引っ張られて概要欄の構造的問題を見落とすことを防ぐため。
実装者は正気ではないかもしれない。よくわからずにPR概要欄を書いたり、AIに生成させてそのまま貼っているかもしれない。 この手順では概要欄だけを読み、レビュアーがこの概要欄を読んで「変更の妥当性を判断できるか」を評価する。
以下の4項目を 必ず全て 評価し、結果をメモする。全項目を評価してから次の手順に進む:
手順3・手順4・手順5では外部Agentにセカンドオピニオンを求める（ただし手順4の「長期視点で命名・設計を考察する」サブセクションは対象外）。手順6では疑わしい点がある場合に限り外部Agentへ相談する。以下のフォールバック順序に従い、推測で判断せず実際に呼び出して試すこと:
codex-consultation を呼び出す。失敗した場合は2へ進むsubagent-consultation を呼び出す。subagentはOpus以上のtierのmodelを指定して起動する。失敗した場合は3へ進むユーザーがCodexのmodel・reasoning effort・Daybreakを指定している時は、各手順のArgsにその指定を含める。 Codexの提供元のフィルタで相談が止められた事をcodex-consultationが報告した時は、2へ進む前に、modelカタログでDaybreak Blueに対応するmodelのうち最新のflagshipでDaybreakを有効にしてやり直すかを、そのmodel名を添えてユーザーに訊く。ユーザーがDaybreakを指定している時、ユーザーに訊けない時、やり直しても止められた時は、1の失敗として扱う。
フォールバックが発生した場合や、外部Agentが利用できなかった場合は、報告書の「レビュー作業において発生した問題」セクションに記載する。
3（main agent単独実行）にフォールバックした場合は、このスキルのコアである批判的思考の連鎖（互いの主張を検討・反論しあい、正確性と網羅性を向上するプロトコル）が機能していないことを意味する。往復検証が欠落した状態でのレビューは本来の精度を持たないため、報告書の「レビュー作業において発生した問題」セクション冒頭に、以下の文言をそのままbold段落として記載すること:
⚠ 警告: 批判的思考の連鎖が機能していません、実行環境が正気である事を疑ってください
各手順では、外部Agentに渡すArgsの内容と、結果の扱い方を記載する。
この手順の目的は、PRタイトル・概要欄・コメントでの説明と実際のコードが一致しているかを確認する、ドキュメントとコードの読み合わせ である。
PR概要欄の author と、各コメントの author を照合し、実装者本人の発言のみを実装の説明として扱う。 他の人が書いた応援コメント、機能に対する期待を込めたコメント、質問等は、実装の説明ではない。 これらを実装の説明と混同すると、整合性の判断を誤る。
齟齬を発見した場合は具体的に記録する。
Agent自身の確認に加えて、外部Agentにも差分とPRタイトル・概要欄の整合性を確認させる。 別の視点でコードを読むため、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に「よく相談して」を含めること。
このSKILL.mdと同じディレクトリにある TEMPLATE.md を読み込み、その形式に従って報告書を作成する。
報告書は会話に出力する。 手順0でPRへのコメント投稿を行うと決めた場合は、同じ内容をPRにもコメントとして投稿する。
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Agent Skillを書く時の心得。SKILL.mdに何を書き、何を書かないかの判断基準を定める。AIが読んで従う文書に共通の心得は、kuden:common-rules-for-agent-instructionsにある。 Agent Skillを作成する時、編集する時、レビュー指摘の採否を決める時に読み込む。
The English summary is being prepared. Showing the original description.
ソースコード中のコメントを書く時の心得。コメントに何を書き、何を書かないかの判断基準と、置く位置、日本語の文体を定める。 ソースコードのコメントを書く時、直す時、レビューする時に読み込む。
The English summary is being prepared. Showing the original description.
リポジトリのセキュリティ調査を領域ごとに進める。同じサービスを構成する複数のリポジトリを束ねて調査できる。 このsessionは調査を指揮し、領域ごとに起動したsubagentが調査してレポートを出力する。 レポートの問題のトリアージと、問題の自動修正、問題を直すpull requestの状態の同期も指揮する。 複数sessionにまたがる長期作業を想定し、実行するたびに現状を確認して続きの作業を行う。 ユーザーが手動で起動する。
The English summary is being prepared. Showing the original description.
セキュリティ調査で検出された問題を1つ修正し、pull requestをready for reviewまで仕上げる。 codepatrol skillが起動したsubagentが実行する。ユーザーが直接呼び出す事は想定していない。
The English summary is being prepared. Showing the original description.
本番に出る前の修正が積まれたrelease pull requestに、デプロイの前後に人間がやる事をまとめたコメントを投稿・更新する。 codepatrol skillが起動したsubagentが実行する。ユーザーが直接呼び出す事は想定していない。
The English summary is being prepared. Showing the original description.
リポジトリの1つの領域をセキュリティ観点で調査し、Codexの批判的レビューを経てレポートを出力する。 codepatrol skillが起動したsubagentが実行する。ユーザーが直接呼び出す事は想定していない。
The English summary is being prepared. Showing the original description.