ba2 Review PR Skill

Pull Request を Claude がレビューする。create-pr と対になるスキルで、レビュー対象はローカルのクローン位置（絶対パス）に一切依存しない。gh CLI が「いまいるリポジトリの GitHub remote」または「渡された PR 参照」から対象を解決するため、メンバーごとにクローン場所がバラバラでも追加設定は不要。

なぜパス指定が不要か: gh は GitHub 上の論理的な PR を対象にする。ba2-skill-installer のようにファイルを物理コピーする配布系スキルとは異なり、レビューはローカルの絶対パスを必要としない。BA2_WORKSPACE 等のパス設定はこのスキルに持ち込まない。

使用方法

/ba2-review-pr                  # カレントリポジトリの「現在ブランチの PR」を自動特定してレビュー
/ba2-review-pr BAX-12345        # ブランチ名 BAX-12345 の PR をレビュー
/ba2-review-pr 123              # PR 番号 #123 をレビュー
/ba2-review-pr <PR の URL>      # 任意リポジトリの PR を URL 指定でレビュー（クローン不要）

引数の有無で対象解決の方法を切り替える（後述の Step 1）。

実行手順

Step 0: 事前チェック

gh auth status で認証状態を確認。未認証ならエラー終了:
- 「gh CLI が未認証です。gh auth login を実行してください。」

レビュー結果を保存する ba2-workspace のパス（BA2_ROOT）を解決する（後述 Step 5 で使う）。レビュー対象の解決とは別物であることに注意。レビュー対象は gh（GitHub 上の論理 PR）で解く一方、保存先はローカルの ba2-workspace クローンを指す必要があるため、ba2-skill-installer / ba2-skills-readme と同じ優先順位で解決する:

# 保存先 ba2-workspace の解決（レビュー対象リポの中で実行されている可能性があるため git 一発では決められない）
BA2_ROOT="${BA2_WORKSPACE:-}"
if [ -z "$BA2_ROOT" ]; then
  GIT_TOP=$(git rev-parse --show-toplevel 2>/dev/null)
  if [ -n "$GIT_TOP" ] && [ "$(basename "$GIT_TOP")" = "ba2-workspace" ]; then
    BA2_ROOT="$GIT_TOP"
  fi
fi
: "${BA2_ROOT:=$HOME/ghq/github.com/kokopelli-inc/ba2-workspace}"
if [ ! -d "$BA2_ROOT/docs" ]; then
  echo "WARN: ba2-workspace が $BA2_ROOT に見つかりません。BA2_WORKSPACE 環境変数で指定してください。レビューは続行し、保存だけスキップします。" >&2
fi
# 苗字（docs/{苗字}/ のフォルダ名）: whoami の末尾 _◯ を除く
USER_NAME=$(whoami | sed 's/_[^_]*$//'); [ -z "$USER_NAME" ] && USER_NAME=$(whoami)

ghq を使っていないメンバーは BA2_WORKSPACE を環境変数で指定する。
$BA2_ROOT/docs が見つからない場合は、レビュー自体は続行し保存だけスキップする（対象解決はパス非依存なのでレビューは常に可能）。

Step 1: レビュー対象の解決（ハイブリッド）

引数を $ARG（無ければ空）として、以下の優先順で PR を一意に特定する。ここで決めた識別子を、以降のコマンドの <PR> に使う（番号 / URL / --head ブランチ名 のいずれか）。

パターンA: 引数なし → 現在ブランチの PR

gh pr view --json number,url,title,headRefName,baseRefName,state

取得できればその PR を対象にする。
取得できない（PR 未作成 / main・develop 上）場合:
- 「現在のブランチに対応する PR が見つかりません。PR 番号・URL・ブランチ名（BAX-XXXX）を指定してください。」と表示して終了。

パターンB: 引数が URL

gh pr view "<URL>" --json number,url,title,headRefName,baseRefName,state

URL にリポジトリ情報が含まれるため、カレントディレクトリがどのリポでも・クローンが無くても動く。

パターンC: 引数が PR 番号（数字のみ）

gh pr view <番号> --json number,url,title,headRefName,baseRefName,state

カレントリポジトリの remote を基準に解決する。別リポの番号を見たいときは --repo owner/name を併用する。

パターンD: 引数がブランチ名（BAX-XXXX 等）

gh pr list --head "<ブランチ名>" --json number,url,title,headRefName,baseRefName,state --jq '.[0]'

該当 PR が無ければ「ブランチ <ブランチ名> の PR が見つかりません」と表示して終了。

判定の目安: https?:// を含む → B、全部数字 → C、それ以外で引数あり → D、引数なし → A。

Step 2: 差分とコンテキストの収集

特定した <PR> に対して:

gh pr view <PR> --json title,body,headRefName,baseRefName,additions,deletions,changedFiles,files,headRepository
gh pr diff <PR>                 # 差分本体

変更ファイル一覧・追加削除行数・PR 本文（概要 / 関連 JIRA）を把握する。
リポジトリ名（保存先ディレクトリ名に使う）を headRepository.name から取得する（URL 指定時は URL 中の <repo> でも可）。
差分が大きい場合はファイル単位で gh pr diff <PR> -- <path> に分割して読む。
関連 JIRA（https://kokopelli-inc.atlassian.net/browse/BAX-XXXX）が PR 本文にあれば、変更意図の確認に使う。

Step 3: レビュー（Claude 本体が実施）

差分を読み、以下の観点で日本語のレビューを構成する。指摘は「ファイル:行」を添えて具体的に、根拠とともに書く。

正しさ / バグ: ロジック誤り、境界条件、null・例外処理、競合・並行性、SQL の条件漏れなど。
設計 / 可読性: 責務の分離、命名、重複、過度な複雑さ。既存コードの規約・周辺スタイルとの一貫性。
セキュリティ: 入力検証、認可漏れ、機密情報のログ出力、インジェクション。
テスト / 動作確認: テストの有無・観点の十分さ。PR 本文の「動作確認」欄が空でないか。
影響範囲: マイグレーション、互換性、ロールバック可否。

指摘は重要度で整理する:

🔴 must（修正必須）: バグ・セキュリティ・データ破壊リスク。
🟡 should（修正推奨）: 設計・可読性・保守性の改善。
🟢 nits（任意）: 細かな好み・体裁。

Step 4: チャットへ出力

レビュー結果をチャットに表示する。この時点では GitHub には何も書かない。

Step 5: docs への保存（常に自動実行）

レビュー結果を ba2-workspace の docs/{苗字}/レビュー/ 配下に Markdown として必ず保存する（ba2-ticket-knowledge-logger が docs にナレッジを残すのと同じ思想。docs/ 配下は main 直プッシュが許可されている運用なので、保存後の commit & push まで自動で行う）。

このスキルは CLAUDE.md の「docs/{苗字}/... への書き込み」許可主体に ba2-ticket-knowledge-logger と並んで明記された例外である（docs/{苗字}/レビュー/ のみ）。それ以外の docs サブディレクトリには書き込まない。

5-1. 保存先ディレクトリとファイルの確定

保存先は 1 レビュー = 1 ディレクトリとし、その中に REVIEW.md を置く。ディレクトリ名は {JIRAチケット番号}_{リポジトリ名}_{PR番号} 形式。

# BA2_ROOT / USER_NAME は Step 0 で解決済み

# JIRA チケット番号: head ブランチ名から [A-Z]+-[0-9]+ を抽出（例: BAX-11452）
JIRA=$(echo "<headRefName>" | grep -oE '[A-Z]+-[0-9]+' | head -1)
# 取れなければ PR 本文中の JIRA URL から抽出、それも無ければ NOJIRA
[ -z "$JIRA" ] && JIRA=$(echo "<PR body>" | grep -oE 'browse/[A-Z]+-[0-9]+' | grep -oE '[A-Z]+-[0-9]+' | head -1)
[ -z "$JIRA" ] && JIRA="NOJIRA"

# リポジトリ名: gh pr view <PR> --json headRepository --jq '.headRepository.name'
#   （URL https://github.com/<owner>/<repo>/pull/<n> の <repo> でも可）
REPO="<リポジトリ名>"      # 例: bigadvance
PRNUM="<PR番号>"           # 例: 2127

REVIEW_DIR="$BA2_ROOT/docs/$USER_NAME/レビュー/${JIRA}_${REPO}_${PRNUM}"
mkdir -p "$REVIEW_DIR"
FILE="$REVIEW_DIR/REVIEW.md"   # 例: docs/takano/レビュー/BAX-11452_bigadvance_2127/REVIEW.md

$BA2_ROOT/docs が無い（Step 0 で WARN）場合は保存をスキップし、その旨をチャットで伝える（レビュー結果自体は Step 4 で提示済み）。
REVIEW.md が既にある場合は全文を上書きせず、本文末尾に再レビューのセクション（## 再レビュー {YYYY-MM-DD HH:MM}）を足す形で更新する。
リポジトリ名・チケット名にファイルシステムで使えない文字（/ 等）が含まれる場合は _ に置換する。

5-2. 保存する Markdown の構造

# レビュー: <PR タイトル>

- **対象 PR**: <url>（#<番号>, head: <headRefName> → base: <baseRefName>）
- **規模**: <changedFiles> files, +<additions> -<deletions>
- **関連 JIRA**: https://kokopelli-inc.atlassian.net/browse/BAX-XXXX（PR 本文にあれば）
- **レビュー日時**: <YYYY-MM-DD HH:MM>（`date "+%Y-%m-%d %H:%M"`）
- **レビュアー**: <USER_NAME>（Claude Code / ba2-review-pr スキル）

## 🔴 must
...

## 🟡 should
...

## 🟢 nits
...

## 総評
（任意。全体所感）

Step 3〜4 で出したレビュー本文をそのまま流用する（チャット表示と保存内容を一致させる）。
機密情報（パスワード・APIキー・トークン・内部IP 等）は保存しない。

5-3. commit & push（自動）

docs/ 配下は main 直プッシュ可の運用なので、当該ファイルだけを add してコミット・プッシュする（ユーザー確認不要）。

cd "$BA2_ROOT" && \
git add "docs/$USER_NAME/レビュー/${JIRA}_${REPO}_${PRNUM}/" && \
git commit -m "review: ${JIRA} ${REPO}#${PRNUM} のレビューを記録

Co-Authored-By: Claude Opus 4.8 <[email protected]>" && \
git push origin main

対象はそのレビューディレクトリのみ add する（無関係な変更を巻き込まない）。
差分が無い（nothing to commit）場合はスキップしてよい。
push に失敗した場合はエラーを表示し、ローカル保存は完了とみなす（後で人手で push できる）。
保存・push 後、保存先 REVIEW.md の GitHub リンクをチャットに提示する: https://github.com/kokopelli-inc/ba2-workspace/blob/main/docs/<USER_NAME>/レビュー/${JIRA}_${REPO}_${PRNUM}/REVIEW.md

Step 6: GitHub の PR への投稿（ユーザーが明示的に希望した場合のみ）

docs への保存とは別に、PR そのものへコメントするかは確認制。末尾に「このレビューを PR(#<番号>) にもコメント投稿しますか？」と確認し、希望した場合のみ実行する。

PR 全体への要約コメント:

gh pr comment <PR> --body "$(cat <<'EOF'
## 🔍 Claude レビュー

{要約と must/should/nits の整理}
EOF
)"

行に紐づくインラインレビューを希望する場合は gh pr review を使う:

gh pr review <PR> --comment --body "{総評}"

投稿は外部に公開される操作なので、必ずユーザーの明示的な確認を取ってから実行する。承認（approve）や変更要求（request-changes）は人間の判断に委ねる（Claude が --approve を勝手に付けない）。

出力フォーマット例

## 🔍 レビュー: BAX-12345 チャットメンバー表示の不整合を修正
対象: #123 (head: BAX-12345 → base: develop) / 7 files, +210 -45

### 🔴 must
- `src/foo/Bar.java:88` — グループ削除後も room_member が残るため…（根拠）

### 🟡 should
- `src/foo/Baz.java:42` — このメソッドは…（提案）

### 🟢 nits
- 命名 `tmp` → `targetRoomId` の方が意図が伝わる

エラーハンドリング

| 状況 | 対応 | |------|------| | gh CLI 未認証 | エラー表示して終了 | | 引数なし・現在ブランチに PR なし | PR 番号 / URL / ブランチ名の指定を促して終了 | | ブランチ名指定で PR が見つからない | その旨を表示して終了 | | 差分が巨大 | ファイル単位に分割して読む。重要ファイルを優先 | | 別リポの PR 番号 | --repo owner/name の併用を案内 | | ba2-workspace の docs が見つからない | レビューは続行し、docs 保存だけスキップ。BA2_WORKSPACE 指定を案内 | | docs の push 失敗 | エラー表示。ローカル保存は完了とみなし、後で人手 push を案内 |

やらないこと

レビュー対象をローカルの絶対パスで指定すること。対象は git / gh コンテキストで解決する（BA2_WORKSPACE は「レビュー結果の保存先 ba2-workspace」を指すためだけに使い、レビュー対象の特定には使わない）。
確認なしの GitHub PR へのコメント投稿・approve・request-changes。
docs/{苗字}/レビュー/ 以外の docs サブディレクトリへの書き込み（レビュー以外のナレッジは ba2-ticket-knowledge-logger の責務）。

ba2 Review PR Skill

なぜパス指定が不要か: gh は GitHub 上の論理的な PR を対象にする。ba2-skill-installer のようにファイルを物理コピーする配布系スキルとは異なり、レビューはローカルの絶対パスを必要としない。BA2_WORKSPACE 等のパス設定はこのスキルに持ち込まない。

使用方法

/ba2-review-pr                  # カレントリポジトリの「現在ブランチの PR」を自動特定してレビュー
/ba2-review-pr BAX-12345        # ブランチ名 BAX-12345 の PR をレビュー
/ba2-review-pr 123              # PR 番号 #123 をレビュー
/ba2-review-pr <PR の URL>      # 任意リポジトリの PR を URL 指定でレビュー（クローン不要）

引数の有無で対象解決の方法を切り替える（後述の Step 1）。

実行手順

Step 0: 事前チェック

gh auth status で認証状態を確認。未認証ならエラー終了:
- 「gh CLI が未認証です。gh auth login を実行してください。」

# 保存先 ba2-workspace の解決（レビュー対象リポの中で実行されている可能性があるため git 一発では決められない）
BA2_ROOT="${BA2_WORKSPACE:-}"
if [ -z "$BA2_ROOT" ]; then
  GIT_TOP=$(git rev-parse --show-toplevel 2>/dev/null)
  if [ -n "$GIT_TOP" ] && [ "$(basename "$GIT_TOP")" = "ba2-workspace" ]; then
    BA2_ROOT="$GIT_TOP"
  fi
fi
: "${BA2_ROOT:=$HOME/ghq/github.com/kokopelli-inc/ba2-workspace}"
if [ ! -d "$BA2_ROOT/docs" ]; then
  echo "WARN: ba2-workspace が $BA2_ROOT に見つかりません。BA2_WORKSPACE 環境変数で指定してください。レビューは続行し、保存だけスキップします。" >&2
fi
# 苗字（docs/{苗字}/ のフォルダ名）: whoami の末尾 _◯ を除く
USER_NAME=$(whoami | sed 's/_[^_]*$//'); [ -z "$USER_NAME" ] && USER_NAME=$(whoami)

ghq を使っていないメンバーは BA2_WORKSPACE を環境変数で指定する。
$BA2_ROOT/docs が見つからない場合は、レビュー自体は続行し保存だけスキップする（対象解決はパス非依存なのでレビューは常に可能）。

Step 1: レビュー対象の解決（ハイブリッド）

パターンA: 引数なし → 現在ブランチの PR

gh pr view --json number,url,title,headRefName,baseRefName,state

取得できればその PR を対象にする。
取得できない（PR 未作成 / main・develop 上）場合:
- 「現在のブランチに対応する PR が見つかりません。PR 番号・URL・ブランチ名（BAX-XXXX）を指定してください。」と表示して終了。

パターンB: 引数が URL

gh pr view "<URL>" --json number,url,title,headRefName,baseRefName,state

URL にリポジトリ情報が含まれるため、カレントディレクトリがどのリポでも・クローンが無くても動く。

パターンC: 引数が PR 番号（数字のみ）

gh pr view <番号> --json number,url,title,headRefName,baseRefName,state

カレントリポジトリの remote を基準に解決する。別リポの番号を見たいときは --repo owner/name を併用する。

パターンD: 引数がブランチ名（BAX-XXXX 等）

gh pr list --head "<ブランチ名>" --json number,url,title,headRefName,baseRefName,state --jq '.[0]'

該当 PR が無ければ「ブランチ <ブランチ名> の PR が見つかりません」と表示して終了。

判定の目安: https?:// を含む → B、全部数字 → C、それ以外で引数あり → D、引数なし → A。

Step 2: 差分とコンテキストの収集

特定した <PR> に対して:

gh pr view <PR> --json title,body,headRefName,baseRefName,additions,deletions,changedFiles,files,headRepository
gh pr diff <PR>                 # 差分本体

変更ファイル一覧・追加削除行数・PR 本文（概要 / 関連 JIRA）を把握する。
リポジトリ名（保存先ディレクトリ名に使う）を headRepository.name から取得する（URL 指定時は URL 中の <repo> でも可）。
差分が大きい場合はファイル単位で gh pr diff <PR> -- <path> に分割して読む。
関連 JIRA（https://kokopelli-inc.atlassian.net/browse/BAX-XXXX）が PR 本文にあれば、変更意図の確認に使う。

Step 3: レビュー（Claude 本体が実施）

差分を読み、以下の観点で日本語のレビューを構成する。指摘は「ファイル:行」を添えて具体的に、根拠とともに書く。

正しさ / バグ: ロジック誤り、境界条件、null・例外処理、競合・並行性、SQL の条件漏れなど。
設計 / 可読性: 責務の分離、命名、重複、過度な複雑さ。既存コードの規約・周辺スタイルとの一貫性。
セキュリティ: 入力検証、認可漏れ、機密情報のログ出力、インジェクション。
テスト / 動作確認: テストの有無・観点の十分さ。PR 本文の「動作確認」欄が空でないか。
影響範囲: マイグレーション、互換性、ロールバック可否。

指摘は重要度で整理する:

🔴 must（修正必須）: バグ・セキュリティ・データ破壊リスク。
🟡 should（修正推奨）: 設計・可読性・保守性の改善。
🟢 nits（任意）: 細かな好み・体裁。

Step 4: チャットへ出力

レビュー結果をチャットに表示する。この時点では GitHub には何も書かない。

Step 5: docs への保存（常に自動実行）

このスキルは CLAUDE.md の「docs/{苗字}/... への書き込み」許可主体に ba2-ticket-knowledge-logger と並んで明記された例外である（docs/{苗字}/レビュー/ のみ）。それ以外の docs サブディレクトリには書き込まない。

5-1. 保存先ディレクトリとファイルの確定

保存先は 1 レビュー = 1 ディレクトリとし、その中に REVIEW.md を置く。ディレクトリ名は {JIRAチケット番号}_{リポジトリ名}_{PR番号} 形式。

# BA2_ROOT / USER_NAME は Step 0 で解決済み

# JIRA チケット番号: head ブランチ名から [A-Z]+-[0-9]+ を抽出（例: BAX-11452）
JIRA=$(echo "<headRefName>" | grep -oE '[A-Z]+-[0-9]+' | head -1)
# 取れなければ PR 本文中の JIRA URL から抽出、それも無ければ NOJIRA
[ -z "$JIRA" ] && JIRA=$(echo "<PR body>" | grep -oE 'browse/[A-Z]+-[0-9]+' | grep -oE '[A-Z]+-[0-9]+' | head -1)
[ -z "$JIRA" ] && JIRA="NOJIRA"

# リポジトリ名: gh pr view <PR> --json headRepository --jq '.headRepository.name'
#   （URL https://github.com/<owner>/<repo>/pull/<n> の <repo> でも可）
REPO="<リポジトリ名>"      # 例: bigadvance
PRNUM="<PR番号>"           # 例: 2127

REVIEW_DIR="$BA2_ROOT/docs/$USER_NAME/レビュー/${JIRA}_${REPO}_${PRNUM}"
mkdir -p "$REVIEW_DIR"
FILE="$REVIEW_DIR/REVIEW.md"   # 例: docs/takano/レビュー/BAX-11452_bigadvance_2127/REVIEW.md

$BA2_ROOT/docs が無い（Step 0 で WARN）場合は保存をスキップし、その旨をチャットで伝える（レビュー結果自体は Step 4 で提示済み）。
REVIEW.md が既にある場合は全文を上書きせず、本文末尾に再レビューのセクション（## 再レビュー {YYYY-MM-DD HH:MM}）を足す形で更新する。
リポジトリ名・チケット名にファイルシステムで使えない文字（/ 等）が含まれる場合は _ に置換する。

5-2. 保存する Markdown の構造

# レビュー: <PR タイトル>

- **対象 PR**: <url>（#<番号>, head: <headRefName> → base: <baseRefName>）
- **規模**: <changedFiles> files, +<additions> -<deletions>
- **関連 JIRA**: https://kokopelli-inc.atlassian.net/browse/BAX-XXXX（PR 本文にあれば）
- **レビュー日時**: <YYYY-MM-DD HH:MM>（`date "+%Y-%m-%d %H:%M"`）
- **レビュアー**: <USER_NAME>（Claude Code / ba2-review-pr スキル）

## 🔴 must
...

## 🟡 should
...

## 🟢 nits
...

## 総評
（任意。全体所感）

Step 3〜4 で出したレビュー本文をそのまま流用する（チャット表示と保存内容を一致させる）。
機密情報（パスワード・APIキー・トークン・内部IP 等）は保存しない。

5-3. commit & push（自動）

docs/ 配下は main 直プッシュ可の運用なので、当該ファイルだけを add してコミット・プッシュする（ユーザー確認不要）。

cd "$BA2_ROOT" && \
git add "docs/$USER_NAME/レビュー/${JIRA}_${REPO}_${PRNUM}/" && \
git commit -m "review: ${JIRA} ${REPO}#${PRNUM} のレビューを記録

Co-Authored-By: Claude Opus 4.8 <[email protected]>" && \
git push origin main

対象はそのレビューディレクトリのみ add する（無関係な変更を巻き込まない）。
差分が無い（nothing to commit）場合はスキップしてよい。
push に失敗した場合はエラーを表示し、ローカル保存は完了とみなす（後で人手で push できる）。
保存・push 後、保存先 REVIEW.md の GitHub リンクをチャットに提示する: https://github.com/kokopelli-inc/ba2-workspace/blob/main/docs/<USER_NAME>/レビュー/${JIRA}_${REPO}_${PRNUM}/REVIEW.md

Step 6: GitHub の PR への投稿（ユーザーが明示的に希望した場合のみ）

PR 全体への要約コメント:

gh pr comment <PR> --body "$(cat <<'EOF'
## 🔍 Claude レビュー

{要約と must/should/nits の整理}
EOF
)"

行に紐づくインラインレビューを希望する場合は gh pr review を使う:

gh pr review <PR> --comment --body "{総評}"

投稿は外部に公開される操作なので、必ずユーザーの明示的な確認を取ってから実行する。承認（approve）や変更要求（request-changes）は人間の判断に委ねる（Claude が --approve を勝手に付けない）。

出力フォーマット例

## 🔍 レビュー: BAX-12345 チャットメンバー表示の不整合を修正
対象: #123 (head: BAX-12345 → base: develop) / 7 files, +210 -45

### 🔴 must
- `src/foo/Bar.java:88` — グループ削除後も room_member が残るため…（根拠）

### 🟡 should
- `src/foo/Baz.java:42` — このメソッドは…（提案）

### 🟢 nits
- 命名 `tmp` → `targetRoomId` の方が意図が伝わる

エラーハンドリング

やらないこと

レビュー対象をローカルの絶対パスで指定すること。対象は git / gh コンテキストで解決する（BA2_WORKSPACE は「レビュー結果の保存先 ba2-workspace」を指すためだけに使い、レビュー対象の特定には使わない）。
確認なしの GitHub PR へのコメント投稿・approve・request-changes。
docs/{苗字}/レビュー/ 以外の docs サブディレクトリへの書き込み（レビュー以外のナレッジは ba2-ticket-knowledge-logger の責務）。

Adoption

octkp/ba2-review-pr

$ install --global

Security Scan Results

SKILL.md

ba2 Review PR Skill

使用方法

実行手順

Step 0: 事前チェック

Step 1: レビュー対象の解決（ハイブリッド）

パターンA: 引数なし → 現在ブランチの PR

パターンB: 引数が URL

パターンC: 引数が PR 番号（数字のみ）

パターンD: 引数がブランチ名（BAX-XXXX 等）

Step 2: 差分とコンテキストの収集

Step 3: レビュー（Claude 本体が実施）

Step 4: チャットへ出力

Step 5: docs への保存（常に自動実行）

5-1. 保存先ディレクトリとファイルの確定

5-2. 保存する Markdown の構造

5-3. commit & push（自動）

Step 6: GitHub の PR への投稿（ユーザーが明示的に希望した場合のみ）

出力フォーマット例

エラーハンドリング

やらないこと

Related Skills

octkp/base-readme

octkp/badev-knowledge-sync

octkp/ba2-ticket-knowledge-reader

octkp/ba2-ticket-knowledge-logger

octkp/ba2-review-pr

$ install --global

Security Scan Results

SKILL.md

ba2 Review PR Skill

使用方法

実行手順

Step 0: 事前チェック

Step 1: レビュー対象の解決（ハイブリッド）

パターンA: 引数なし → 現在ブランチの PR

パターンB: 引数が URL

パターンC: 引数が PR 番号（数字のみ）

パターンD: 引数がブランチ名（BAX-XXXX 等）

Step 2: 差分とコンテキストの収集

Step 3: レビュー（Claude 本体が実施）

Step 4: チャットへ出力

Step 5: docs への保存（常に自動実行）

5-1. 保存先ディレクトリとファイルの確定

5-2. 保存する Markdown の構造

5-3. commit & push（自動）

Step 6: GitHub の PR への投稿（ユーザーが明示的に希望した場合のみ）

出力フォーマット例

エラーハンドリング

やらないこと

Related Skills

octkp/base-readme

octkp/badev-knowledge-sync

octkp/ba2-ticket-knowledge-reader

octkp/ba2-ticket-knowledge-logger