GitHub PR の CI ステータス (`gh pr checks`)・コード品質・セキュリティ (OWASP Top 10)・Conventional Commits 準拠をレビューする。`gh pr review --approve/--request-changes/--comment` でレビュー投稿も可能。「PR #N をレビュー」「PR レビューして」などで使用。ローカル diff のレビューには implement-review を使用。

implement review pr GitHub PR の CI ステータス・コード品質・セキュリティをレビューします。前提条件 gh CLI がインストールされ、認証済みであることフロー Step 1: PR 情報を取得する Step 2: CI ステータスを確認する全チェックが pass しているか確認。失敗している場合は詳細をユーザーに報告。 Step 3: PR タイトルを確認する Conventional Commits 形式への準拠を確認: type(scope): subject の形式有効な type（feat / fix / docs / refactor / test / chore / style / build / ci / perf） subject が 72 文字以内 Step 4: ①仕様準拠レビュー Agent ツールに委譲して仕様への準拠を確認: 確認項目: PR に紐づく Issue の要件・受け入れ条件を充足しているか out of scope の実装が混入していないか PR タイトル・body の記述が変更内容と整合しているか Step 5: ②コード品質レビュー（OWASP セキュリティ含む） Agent ツールに委譲してコード品質・セキュリティを確認: 確認項目（品質）: アーキテクチャ準拠（コンポーネント階層、配置先）命名規則 Import ルール不要な再描画リスクテストカバレッジ確認項目（セキュリティ、必須）: OWASP Top 10 API キー・シークレット漏洩入力バリデーション認証・認可の実装機密データの取り扱い Step 6: レビューレポートを生成する out of scope 項目を検出した場合は本レポートに「対象外とした項目」と対応案を含める（後述の「実装対象外（out of scope）の扱い」を参照）。切り出し先 Issue 番号はユーザー承認後の起票で確定するため、レポート時点では 'TBD' と記載する。out of scope の収集はレビュー中（Step 4〜5）に行う。 Step 7: GitHub にレビューコメントを投稿する（オプション）ユーザーに確認してから投稿: 実装対象外（out of scope）の扱いこのスキルは読み取り専用のレビューが原則だが、PR レビューの過程で対応すべきだが現スコープ外と判断した事項（未対応の改善・別機能・技術的負債・後続作業）を検出した場合は、放置せず追跡する。 out of scope 検出時に限り、ユーザー承認を得たうえで Issue へのコメント/起票という書き込み操作を行う例外とする。手順 1. 既存 Issue を確認する対象を実装している既存の open Issue があるか検索する: キーワードは "${KEYWORD}" でクォートして渡す。 2. ユーザーに提示して承認を得る out of scope 項目・既存 Issue の有無・対応案（既存 Issue へのコメント追加 or 新規起票）をレビューレポートに含めてユーザーに提示する。承認を得てから実行する（確認なしに Issue 操作をしない）。 3. 既存 Issue がある場合: コメントを追加する 4. 既存 Issue がない場合: 新規起票する create issue tree が導入されていればそれを使用（既存ルートへの紐付けは root <ルートissue番号）、未導入なら create issue を使用して、適切な親 Issue 配下に起票する。タイトルは Conventional Commits 形式とする。 5. PR 本文・レビューレポートに明記する out of scope 項目はレビュー中（Step 4〜5）に収集し Step 6 のレポートに含める。Issue への書き込み操作は承認後に行う。Step 6 のレビューレポートおよび Step 7 の GitHub レビューコメントには「対象外とした項目」と対応案を記載する。切り出し先 Issue 番号は承認後の起票で確定するため、レポート時点では 'TBD' とし、起票後に確定番号を GitHub コメントで追記する。セキュリティ注記 : gh へ渡すキーワード・コメント本文は変数を "${var}" でクォートし、本文は HEREDOC（ <<'EOF' ）で渡してインジェクションを防ぐ。検証レビュー完了後、レポートに「①仕様準拠」「②コード品質/セキュリティ」の両セクションが記述されていることを確認する（ .claude/rules/verification.md ）。セキュリティ問題（HIGH）が残る場合は完了を宣言しない。よくある失敗問題回避策仕様準拠を確認せずにコード品質レビューに入る Step 4（①仕様準拠）→ Step 5（②コード品質/セキュリティ）の順を守るセキュリティレビューをコード品質と独立した別セクションで報告する ②コード品質セクション内の「セキュリティ（OWASP）」小節に統合して報告する CI 失敗を確認せずにコードレビューに進む Step 2 で CI が全チェック通過していることを先に確認する注意事項セキュリティ問題（HIGH）がある場合は request changes を推奨する CI が失敗している場合はレビューをブロックすることを推奨する sandbox 環境での実行このスキルはネットワーク越しの GitHub 操作（ gh pr view / gh pr checks 等）を必須とする。既定フローはすべて読み取りで書き込みを行わないが、 gh pr review によるレビュー投稿を選択した場合は書き込みを伴う。該当コマンドはコマンド単位で sandbox 無効にして実行する。 gh pr review を実行する場合も同様にコマンド単位で sandbox 無効にする。ネットワーク遮断を解除できない環境では実行できない。

implement-review-pr