+---------------------------------------------------------------+
| レビューの鉄則                                                  |
+---------------------------------------------------------------+
| 1. 推測でレビューしない - 必ずコードを読んで根拠を示す              |
| 2. 6つの観点を漏れなくチェックする                                |
| 3. 指摘には必ず根拠（該当コード・行番号）を添える                   |
| 4. 数値・事実を根拠にする場合は必ずソースを確認する                  |
| 5. 人間向けとAI向けの2形式で指摘を書く                            |
| 6. 重大度を正確に分類し、過剰な指摘を避ける                        |
| 7. 再レビュー時は前回指摘の修正確認を必ず行う                      |
+---------------------------------------------------------------+

PR URLまたは番号を受け取る
      |
1. PR情報の取得（diff、説明文、関連ファイル一覧）
      |
2. 変更ファイルの分類と優先度付け
      |
3. 6観点でのレビュー実行
   a. セキュリティ
   b. ドキュメントとの乖離
   c. 可読性・複雑度
   d. ライブラリ選定の妥当性
   e. PR説明の適切性
   f. 既知脆弱性の検出
      |
3.5. PR内横断チェック（同一パターンの問題を他ファイルでも確認）
      |
4. 指摘の重大度分類と整理
      |
5. ★ レビュー結果の承認確認 ★（必須ゲート）
   - レビューサマリーをユーザーに提示
   - AskUserQuestionでレビュー結果投稿の承認を確認
      |
6. PRコメントの作成・投稿
   - サマリーコメント（PR全体）
   - インラインコメント（個別指摘）

PR URLまたは番号 + 再レビュー指示を受け取る
      |
1. PR情報の取得（最新diff、前回レビューコメント）
      |
2. 前回指摘の修正確認
   a. 各指摘に対する修正状況を確認
   b. 修正済み / 未修正 / 部分修正を分類
      |
3. 新規変更に対する6観点レビュー
   a. セキュリティ
   b. ドキュメントとの乖離
   c. 可読性・複雑度
   d. ライブラリ選定の妥当性
   e. PR説明の適切性
   f. 既知脆弱性の検出
      |
3.5. PR内横断チェック（同一パターンの問題を他ファイルでも確認）
      |
4. 指摘の重大度分類と整理（前回指摘の修正状況を含む）
      |
5. ★ レビュー結果の承認確認 ★（必須ゲート）
   - レビューサマリーをユーザーに提示
   - AskUserQuestionでレビュー結果投稿の承認を確認
      |
6. PRコメントの作成・投稿
   - 前回指摘の修正状況サマリー
   - 新規指摘（サマリー + インライン）

# PR差分の取得
gh pr diff <PR番号>

# PR詳細の取得
gh pr view <PR番号>

# PRの変更ファイル一覧
gh pr diff <PR番号> --name-only

# 前回のレビューコメント取得（再レビュー時）
gh api repos/{owner}/{repo}/pulls/{PR番号}/reviews
gh api repos/{owner}/{repo}/pulls/{PR番号}/comments

指摘を発見した場合の横断チェック手順:
1. 指摘のパターンを抽出する（例: 「不正確なテスト数の記載」）
2. PR内の全変更ファイルで同様のパターンを検索する
3. 別コミットで追加された関連ファイルも確認対象に含める
4. 同一パターンの問題が複数見つかった場合はまとめて指摘する

AskUserQuestion:
  question: "上記のレビュー結果をPRに投稿してよろしいですか？"
  options:
    - label: "投稿する"
      description: "レビュー結果をPRコメントとして投稿します"
    - label: "修正してから投稿"
      description: "レビュー内容を修正してから投稿します"
    - label: "投稿しない"
      description: "レビュー結果の投稿を中止します"

+---------------------------------------------------------------+
| 重要: この承認確認は省略できない                                   |
+---------------------------------------------------------------+
| - Approve / Request Changes / Comment いずれの判定でも必須       |
| - ユーザーの承認なしにPRコメントを投稿してはならない                 |
| - 承認確認前にレビューサマリーの全体像を必ず提示すること              |
+---------------------------------------------------------------+

+---------------------------------------------------------------+
| 投稿時の注意事項                                                 |
+---------------------------------------------------------------+
| - 自身のPRには APPROVE / REQUEST_CHANGES を付与できない           |
|   → 自身のPRの場合は event を "COMMENT" にフォールバックする      |
| - commit_id は gh pr view --json headRefOid で取得する          |
| - body やコメントに JSON コードブロック・特殊文字を含む場合、      |
|   -f フラグではエスケープ問題が発生しやすいため                   |
|   --input による JSON ファイル入力を使用する                      |
+---------------------------------------------------------------+

# 1. commit SHA を取得
COMMIT_SHA=$(gh pr view <PR番号> --json headRefOid --jq '.headRefOid')

# 2. JSONファイルにレビュー内容を書き出す（Write ツール推奨）
# /tmp/review_body.json に以下の構造で書き出す:
# {
#   "commit_id": "<COMMIT_SHA>",
#   "event": "APPROVE | REQUEST_CHANGES | COMMENT",
#   "body": "レビュー本文（任意）",
#   "comments": [
#     {
#       "path": "src/example.ts",
#       "line": 42,
#       "body": "インラインコメント本文"
#     }
#   ]
# }
# ※ 自身のPRの場合は event を "COMMENT" にフォールバックすること

# 3. 投稿
gh api repos/{owner}/{repo}/pulls/{PR番号}/reviews \
  --method POST --input /tmp/review_body.json

**[重大度]** 観点名

問題の概要と修正方針を簡潔に説明する。
（詳細なコード差分はAI向けJSONに記載するため、ここでは重複させない）

<details>
<summary>AI向け指示</summary>

```json
{
  "id": "F-001",
  "file": "ファイルパス",
  "line": "[行番号]",
  "severity": "critical | warning | suggestion | nitpick",
  "category": "security | iam-permissions | docs-drift | internal-consistency | readability | library | pr-description | known-vulnerability",
  "title": "問題の端的な説明",
  "fix": {
    "old_text": "置換対象のコードテキスト",
    "new_text": "置換後のコードテキスト",
    "description": "補足説明（任意）"
  },
  "fix_strategy": {
    "approach": "推奨する修正アプローチの説明",
    "alternatives": ["代替案1の説明", "代替案2の説明"],
    "impact": "修正による影響範囲（他ファイル、依存コンポーネント等）",
    "effort": "small | medium | large"
  },
  "context": "該当行の前後3行程度のコード断片",
  "scope": "fix-in-this-pr | fix-in-follow-up | wont-fix",
  "rule": "関連するルールやパターン名（例: OWASP-A03, SRP, etc.）",
  "verification_hint": "修正後に確認すべきチェックポイント（例: 関連ファイルとの整合性確認）"
}

{
  "approach": "文字列結合をパラメータ化クエリに置換する。プロジェクト内の既存パターン（src/repositories/baseRepository.ts）に合わせる",
  "alternatives": [
    "ORMのクエリビルダーを使用する方法もあるが、現在のプロジェクトでは生SQLを使用する方針"
  ],
  "impact": "同リポジトリ内の他のRepository（orderRepository.ts, productRepository.ts）にも同様の文字列結合パターンがある可能性",
  "effort": "medium"
}

## 再レビュー結果

### 前回指摘の修正状況

| # | 指摘内容 | 重大度 | 状態 | コメント |
|---|---------|--------|------|---------|
| 1 | [指摘概要] | critical | resolved | 適切に修正済み |
| 2 | [指摘概要] | warning | unresolved | 未修正 - 対応をお願いします |

- resolved: X件
- partially-resolved: X件
- unresolved: X件

### 新規指摘

（通常の6観点レビュー結果）

- 推測に基づくレビュー（コードを読まずに指摘する）
- 個人の好みだけを根拠にした指摘（明確な理由なしの「こう書くべき」）
- 裏取りなしに数値・事実を断定する指摘（例: 「テスト数は243件」と述べる前に
  実際のテスト数をカウントする。不確実な場合は「〜の可能性がある」と表現する）
- 変更範囲外のコードへの指摘（ただしセキュリティ問題は例外）
- 過剰な nitpick（レビュー全体が些細な指摘で埋まる状態）
- 人間向け・AI向けのどちらか一方だけの記載
- 再レビュー時に前回指摘の修正確認を省略すること
- ユーザーの承認なしにPRコメントを投稿すること（承認確認ゲートの省略）

チームリーダー（レビュー統合・サマリー作成に専念）
    |
    +-- レビュアーA: セキュリティ・既知脆弱性観点担当
    |   - コードのセキュリティ問題（認証・認可、入力検証、秘密情報管理）と
    |     依存パッケージの既知脆弱性（CVE）を一貫してチェック
    |   - 両観点を同一レビュアーが担当することで、コード側の脆弱性と
    |     依存パッケージ側の脆弱性を統合的に評価できる
    |
    +-- レビュアーB: 可読性・複雑度観点担当
    |   - 命名、関数長、ネスト、複雑度を集中チェック
    |
    +-- レビュアーC: ドキュメント乖離・ライブラリ・PR説明観点担当
        - 仕様との整合性、依存関係の妥当性、PRタイトル・説明文の適切性を集中チェック