Menu
既存の PR を起点に、タイトル・本文・テスト・コード/UX/e2e レビュー・CodeRabbit の状況を横断チェックし、未実施のレビューを補ってマージ可能な状態かを判定する。PR のレビュー（点検）を依頼されたときに使用
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | vk-pr-review |
| description | 既存の PR を起点に、タイトル・本文・テスト・コード/UX/e2e レビュー・CodeRabbit の状況を横断チェックし、未実施のレビューを補ってマージ可能な状態かを判定する。PR のレビュー（点検）を依頼されたときに使用 |
前提条件（軟ゲート）: このスキルは、対象リポジトリの owner が許可リスト
org.allowed_owners（~/.vk-agents/config.json）に含まれる場合はそのまま、含まれない場合はユーザー確認のうえ使用できます。判定手順はrules/repository-access.mdを参照。
既存の PR を起点に、レビュー観点・テスト・各種レビューの実施状況を満たし、マージ可能かを横断点検します。不足レビューはこのスキル内で実施し、最後に結果を PR へサマリーコメントとして投稿します。
以下の表現を含む場合に使う:
https://github.com/vektor-inc/xxx/pull/123 または #123）gh repo view --json nameWithOwner で <REPO> を補完するwp-env-port=NNNN 形式で渡せる（e2e で麗美がローカル環境を使う場合の衝突回避用。testsPort は NNNN + 1）主役はメイン Claude（点検役）です。各レビュー担当（安藤・植草・麗美）は Agent ツール（subagent_type: general-purpose）でサブエージェントとして起動します。メンバーを呼ぶ際は対応する persona.md を Read してから Agent に渡します。
$ARGUMENTS から PR の URL / 番号を取得し、<REPO>（owner/repo）と <PR>（番号）を確定する
rules/repository-access.md のゲート判定を行う（軟ゲート）。owner が許可リストに含まれない場合は「⚠️ 許可リスト外のリポジトリです（オーナー: <オーナー名>）。続行しますか？」と確認し、明示承認された場合のみ続行する
PR の基本情報を取得する:
gh pr view <PR> -R <REPO> --json title,body,headRefOid,commits,comments,reviews,files,state,isDraft,author,labels
state が MERGED / CLOSED ならその旨を報告して終了する
続行可否の確認: このスキルは最後に点検結果サマリーを PR に投稿するため、先に「いま点検してよい PR か」を確認する。次のいずれかに当てはまる場合は、点検前にユーザーへ「点検を実行し、結果コメントをPRへ投稿してよいですか？」と確認する。確認待ちラベルの有無や Draft 状態は、いま点検してよいかのシグナルとし、明示的な続行承認が得られた場合のみ続行する。
labels に 確認待ち / 1人目確認待ち / 2人目確認待ち のいずれも含まれないisDraft が true（Draft 状態の PR）上記いずれにも当てはまらない（確認待ちラベルあり かつ 非 Draft）場合は、確認せず続行する。
author.login（PR 作成者の GitHub アカウント）と author.is_bot（GitHub が返す bot 判定フラグ）を控える。手順10の通知（メンション）先判定に使う
rules/change-title.md を Read で読み込む（記憶で判定しない）rules/pull-request.md を Read で読み込むgh pr diff <PR> -R <REPO> で実際の差分を取得するrules/changelog.md を Read で読み込む（記載対象ファイル・記載タイミング・更新不要なケース・記載言語・バージョン番号の扱いなどを確認する）rules/changelog.md の「記載対象ファイル」に従い、対象の changelog ファイル（WordPress プラグインなら readme.txt の == Changelog ==、その他は CHANGELOG.md 等）を特定し、差分（手順3で取得）に含まれるか確認するrules/changelog.md の「更新不要なケース」（ワークフロー設定・開発環境設定・未リリース機能の不具合修正など）に該当する場合は記載不要とみなすrules/changelog.md / rules/change-title.md のルール（分類・体言止め・記載言語・バージョン番号を書かない・プレースホルダーを書かない等）に沿っていない場合は、その箇所を控えるrules/coding-rules.md を Read で読み込む（記憶で判定しない）readme.txt の有無・言語から記載言語を判定する（判定基準は coding-rules.md を唯一の正とする）。WordPress プラグインなら差分やリポジトリ直下の readme.txt を確認するreadme.txt が無い／changelog に日本語が含まれる）で、追加・変更されたコメントに 英語が併記されていないか を確認する。逆に英日併記プロジェクトで片方が欠けていないかも確認するrules/testing/phpunit.md を Read で読み込み、対応する PHPUnit テストの有無とルール適合を確認する
rules/pull-request.md の「PHPUnit テストの確認」にある例外（フック・フィルターのみ等、単体テストになじまない実装／環境制約）に該当するかを判断するrules/testing/e2e.md を Read で読み込み、テストがルールに沿って書かれているか確認する各レビュー（コード=安藤・UX=植草・e2e=麗美）が、PR 内の最後のコード改変よりも後に実施済みか判定する。古い（最後の push より前の）レビューしか無ければ、改変後のコードがレビューされていないため「未実施」とみなす。
gh pr view <PR> -R <REPO> --json commits --jq '.commits[-1].committedDate'
rules/code-review.md で定められたコメント冒頭のエージェント名表記による（例: 🔍 保（コードレビュー）、🎨 植草（UXレビュー）、🧪 麗美（e2eテスト））手順7で「未実施」と判定されたレビューを実施する。各レビューの観点・基準はルールファイルを唯一の正とし、ここには複製しない。
REPO_ROOT/skills/staff-security/persona.md を Read し、Agent（general-purpose）で安藤を起動する。prompt には persona とレビュー対象（<REPO> / <PR> / 差分）を渡す。安藤は rules/code-review.md に基づきセキュリティ・品質・PR 内完結変更への過剰な互換処理をチェックする。出力に「レビュー結果: PASS」が含まれれば通過.css / .scss / .jsx / .tsx / .html / PHP テンプレートの変更がある場合に実施する。純粋なロジック変更で UI への影響がない場合は省略可（省略理由を控える）。REPO_ROOT/skills/staff-ux/persona.md を Read して Agent で起動するSkill ツールで staff-review を起動するか、REPO_ROOT/skills/staff-review/persona.md を Read して Agent で起動する。wp-env-port が渡されていれば麗美への依頼に含める。UI 変更がなく確認対象が無い場合は省略可（省略理由を控える）rules/code-review.md の「GitHub PR レビュー時のコメント投稿」に従うrules/coderabbit-monitoring.md を Read で読み込む（START 取得タイミングの罠があるため記憶で実行しない）。読み込んだ「前提条件」でスキップ判定になった場合は、以下 2-3 の監視ステップを 待機なしでスキップ し、サマリーには同ルールの前提条件に沿って理由を記載してステップ 10 へ進むCurrently processing / review in progress のままでないか、No actionable comments / Actionable comments posted 等の本レビュー特有の文言で完了しているかを rules/coderabbit-monitoring.md の判定手順で確認するrules/coderabbit-monitoring.md の監視フローに従う（Bash の run_in_background を使い Monitor は使わない）点検結果を1つのサマリーコメントにまとめ、PR に投稿する（gh pr comment <PR> -R <REPO>）。この投稿は省略不可（全項目クリアの場合も、点検済みであることを示すために投稿する）。
サマリーを書く前に、PR の既存議論を最新状態で再取得して総浚いする（必須）。 手順8・9でレビューコメントが新たに投稿されているため、手順1で取得したキャッシュは使わず再取得する。総浚いの取得方法（3経路・--paginate 必須）は rules/coderabbit-monitoring.md の「PR コメントの総浚い（既存議論の全取得）」に従う（--json comments だけだと CodeRabbit の指摘の大半が乗るインラインコメントを取りこぼすため、3経路すべてが必須）。
取得した全コメント・レビューを使い、各指摘が既存議論で言及・議論されていないか照合する。照合結果に応じて次のように扱う:
| 状態 | サマリーへの書き方 |
|---|---|
| 既存コメントで議論あり → 解決済み | 「既存コメントで対応済み」と明記する |
| 既存コメントで議論あり → 未解決のまま残っている | 引き続き指摘として書く。コメント URL を参照先として添える |
| 既存コメントで議論なし | 通常どおり指摘する |
「既存コメントで対応済み」は省力化の口実にしない（必須）。 CR を含む既存コメントの指摘は、点検が超えるべき "床（最低ライン）" であり、それに乗っかるだけでは CR のラバースタンプになる。照合後、各観点について 「CR の静的解析では拾えない、その観点ならではの指摘が他に無いか」を必ず一度問い直す（セキュリティ文脈・権限/境界、UX 意図・既存ユーザー影響、実フロー・回帰）。重複しない追加観点が見つかればサマリーに足し、本当に無ければ「追加指摘なし（既存コメントを超える所見なし）」と明記する（黙って省略しない）。
書式は rules/decision-record.md に従う（1行目 Comment by vk-agents / 2行目 Status:。作成者が対応すべき指摘があるとき・すべてクリアなときは no-action、ユーザーの判断が必要または担当不明なときは waiting-input）。
要修正・要調整がある場合に誰へメンションして通知するかは、rules/decision-record.md の「通知（メンション）先のルール」に従う（Status の値ではなく「次のアクションを誰が持つか」で決める）。点検結果を次の3つに当てはめる:
Status: no-action とし（点検タスク自体は完了しており、通知はメンションが担う）、手順1で控えた author.login を使い、Status: 行の次の行に @<author.login> 以下に要修正・要調整の点があります。ご確認をお願いします 🙏 を記載して、作成者に通知が届くようにする。要対応項目が複数あっても、まとめてこの1行で依頼する（項目ごとに個別メンションはしない）Status: waiting-input の記録として残す（ユーザー確認待ちのシグナル）author.is_bot が true。CodeRabbit / dependabot / GitHub App など）、または対応すべき担当が不明な場合 — メンションは付けず、「担当者の確認が必要」として Status: waiting-input の記録を残す（author.login の見た目で bot 判定しない）すべてクリア（Status: no-action）の場合はメンションを付けない。上記2・3のメンションを伴わないケースは GitHub 通知が誰にも飛ばないため、Status: waiting-input の記録が検知・追跡の役割を担う（オーケストレーター（vk-orchestrator）が監視する前提。記録の投稿は省略不可）。orchestrator が存在しない手動運用（features.task_queue: false かつ headless=1 も無い 等の無人モードでない場合）では waiting-input を拾う者がいないため確認はターミナルで行うが、その場合も記録（コメント投稿）は省略しない。
サマリーには以下を含める:
rules/coderabbit-monitoring.md の前提条件に従って記載）記述例:
Comment by vk-agents
Status: no-action
**🔍 vk-pr-review（PR 点検）の結果**
**🗂 点検サマリー**
- 📝 タイトル: ✅ 適合
- 📄 本文・実態整合: ✅ 適合
- 📒 changelog: ✅ 適合
- 🧷 コーディングルール（コメント言語等）: ✅ 適合
- 🧪 テスト: ✅ 適合（PHPUnit 追加済み）
- 🔒 安藤（コードレビュー）: ✅ 実施 PASS
- 🎨 植草（UX）: ⏭️ スキップ — 純粋なロジック変更で UI 変更が無いため
- 🧪 麗美（e2e）: ✅ 実施 PASS
- 🐰 CodeRabbit: ✅ 完了・未対応の指摘なし
総評: マージ可能な状態です。
要修正・要調整があり、その解消を PR 作成者が行う場合（作成者をメンションする）の記述例:
Comment by vk-agents
Status: no-action
@octocat 以下に要修正・要調整の点があります。ご確認をお願いします 🙏
**🔍 vk-pr-review（PR 点検）の結果**
**🗂 点検サマリー**
- 📝 タイトル: ⚠️ 要修正 — 分類表記が無いため `[ 不具合修正 ][ ブロック名 ] …` の形にする
- 📄 本文・実態整合: ✅ 適合
- 📒 changelog: ⚠️ 不足 — `readme.txt` の `== Changelog ==` への追記が必要
- 🧷 コーディングルール（コメント言語等）: ✅ 適合
- 🧪 テスト: ✅ 適合
- 🔒 安藤（コードレビュー）: ✅ 実施 PASS
- 🎨 植草（UX）: ⏭️ スキップ — UI 変更が無いため
- 🧪 麗美（e2e）: ✅ 実施 PASS
- 🐰 CodeRabbit: ✅ 完了・未対応の指摘なし
総評: 上記2点（タイトル・changelog）の対応後にマージ可能な状態です。
サマリー内容をユーザーにも報告する。マージ判断はユーザーに委ねる（このスキルは勝手にマージしない）。
wp db import / wp db reset / wp db export などの DB 操作は 必ず実行前にユーザーに確認する。麗美にもこの点を伝達するrules/coderabbit-monitoring.md の「タイムアウト時の手動確認」を実施し、それでも判断できなければユーザーに状況を報告する。「指摘なし」と断定しないvk-orchestrator をリリースする。同梱する vk-terminals / vk-agents を最新にそろえてから、バージョン付与・CHANGELOG 確定・タグ push まで一気通貫で行う。「orchestrator をリリース」「vk-orchestrator-release」で起動。
メイン Claude がディレクター（司）として振る舞う。GitHub issue管理、和田（エンジニア）への実装指示、植草（UX）との連携・確認を統括する。
e2eテスト・UIテスト担当（麗美）をサブエージェントとして起動する。PRに対してPlaywrightでブラウザ操作テストを実施する。コードレビューはスコープ外。
GitHub issue の URL を受け取り、司（staff-director）が内容を分析→適切なメンバーに委任→完了確認→報告まで一貫して行う
VK Orchestrator の初回セットアップを対話で行う。doctor で不足項目を検知し、モード選択（ローカル/GitHub）→ 依存順のヒアリング → 3 ファイル（A/B/C）への保存 →（GitHub モード時のみ）ラベル登録 → 再 doctor で確認まで伴走する。
リードエンジニア（安藤保）をサブエージェントとして起動する。コード品質・レビューの最終責任者。設計・可読性・保守性・パフォーマンス・セキュリティの全般をレビュー。「安藤さん」「保さん」で呼び出し可能。