implement-review-pr

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

implement-review-pr

GitHub PR の CI ステータス・コード品質・セキュリティをレビューします。

前提条件

• gh CLI がインストールされ、認証済みであること

フロー

Step 1: PR 情報を取得する

gh pr view <number-or-url>
gh pr diff <number-or-url>

Step 2: CI ステータスを確認する

gh pr checks <number-or-url>

全チェックが 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）に行う。

## PR #123: feat(auth): 新機能追加

### CI Status
✅ All checks passed

### Title Compliance
✅ Conventional Commits 準拠

### ①仕様準拠レビュー
✅ 問題なし
⚠️ 要確認: 受け入れ条件 X が未実装

### ②コード品質レビュー

#### コード品質
✅ 問題なし
⚠️ 要改善: `src/Foo.tsx:10` — 説明
❌ 要修正: `src/Bar.tsx:20` — 説明

#### セキュリティ（OWASP）
✅ セキュリティ問題なし
❌ [HIGH] `src/api.ts:5` — 説明

Step 7: GitHub にレビューコメントを投稿する（オプション）

ユーザーに確認してから投稿:

gh pr review <number> --comment --body "..."
# または
gh pr review <number> --approve
gh pr review <number> --request-changes --body "..."

実装対象外（out-of-scope）の扱い

このスキルは読み取り専用のレビューが原則だが、PR レビューの過程で対応すべきだが現スコープ外と判断した事項（未対応の改善・別機能・技術的負債・後続作業）を検出した場合は、放置せず追跡する。out-of-scope 検出時に限り、ユーザー承認を得たうえで Issue へのコメント/起票という書き込み操作を行う例外とする。

手順

1. 既存 Issue を確認する 対象を実装している既存の open Issue があるか検索する:

gh issue list --state open --search "${KEYWORD}"

キーワードは "${KEYWORD}" でクォートして渡す。

2. ユーザーに提示して承認を得る out-of-scope 項目・既存 Issue の有無・対応案（既存 Issue へのコメント追加 or 新規起票）をレビューレポートに含めてユーザーに提示する。承認を得てから実行する（確認なしに Issue 操作をしない）。

3. 既存 Issue がある場合: コメントを追加する

gh issue comment "${ISSUE_NUMBER}" --body "$(cat <<'EOF'
## 実装サポート情報（別作業から検出）

### 検出背景
PR レビュー（PR #N）の過程で発見した事項。

### 関連ファイル・シンボル
- `src/path/to/file.ts` — 対象関数名・クラス名

### パッケージ・サービスから見た役割・影響範囲
（このシンボルの担う境界、呼び出し元/呼び出し先）

### 着手時の注意点・依存関係
（依存パッケージ、順序制約など）
EOF
)"

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 無効にする。ネットワーク遮断を解除できない環境では実行できない。