pr-respond

name	pr-respond
description	PRのレビューコメント・CI失敗・Changes Requestedに批判的思考で対応を検討し自律的に実行する。スコープ内なら対応する・しないを判断してコード修正/返信、スコープ外ならIssueを作成してコメントする。「レビューコメントに対応して」「CIが落ちた」「Changes requestedに返信して」「指摘を直して」のときに使う。

pr-respond — 批判的思考によるレビュー対応

レビューコメントを批判的思考で評価し、スコープ判定に基づいて対応を決定・実行する。 「妥当か」「スコープ内か」を先に判断してから動く。

引数

PR番号（#42）または空（現在のブランチのPRを自動検出）。

---

Step 1: 対応事項の収集

# 未解決のレビュースレッド
gh pr view <番号> --json reviewThreads

# CI失敗の詳細
gh pr checks <番号>
gh run view <failed-run-id> --log-failed 2>/dev/null | head -100

# PR本文（Issueからのスコープ情報）
gh pr view <番号> --json body,title,url

---

Step 2: 各コメントの批判的評価

すべてのコメントを以下のフレームワークで評価してから対応を決定する。

思考フレームワーク

① スティールマン（最も強い解釈） このコメントの最も正当な版は何か？ 批判者の主張を最も説得力のある形で再構成する。

② 第一原理（根本的な正しさ） コードの正確性・安全性・保守性の観点で本質的に正しいか？ 慣習・好みの問題か、それとも実際にバグやリスクがあるか？

③ プリモーテム（無視した場合のリスク） このコメントを無視してマージした場合、1ヶ月後に何が起きるか？ クラッシュ・データ破損・保守困難・混乱のどれか？

④ スコープ判定（最重要） このPRのIssueで定義した「やること」の範囲内か？

• スコープ内 → 対応するかしないかを決定
• スコープ外 → Issue化して対応しない

評価結果の分類

分類	条件	アクション
対応する（スコープ内・妥当）	正当な指摘でPRのスコープ内	コードを修正してコミット
対応しない（スコープ内・不採用）	スコープ内だが採用しない根拠がある	根拠を添えて丁重に辞退
Issue化（スコープ外）	改善提案だがこのPRの範囲外	Issue作成 → コメントで追跡を通知
CI失敗（バグ）	テスト・ビルドが壊れている	根本原因を修正してコミット

---

Step 3: 実行前に対応計画を表示

評価結果 (N件):

✅ 対応する (N件)
  1. @reviewer (src/auth/token.ts:42)
     "SimpleDateFormatはスレッドセーフでない"
     → 評価: 正当。プリモーテム: 本番で競合状態によるクラッシュが起きる
     → DateTimeFormatterに修正します

🚫 対応しない (N件)
  2. @reviewer (src/api/client.kt:88)
     "このメソッドをstaticにした方がいい"
     → 評価: 好みの問題。DI可能にするためinstanceメソッドが必要
     → 根拠を返信します（コード変更なし）

📋 Issue化（スコープ外）(N件)
  3. @reviewer: "エラーメッセージをi18n対応にすべき"
     → 評価: 妥当な提案だが今回のスコープ（認証機能追加）の外
     → Issue作成 → コメントで追跡を通知します

🔧 CI修正 (N件)
  4. CI失敗: AuthTokenTest でNullPointerException
     → 根本原因: testExpiry でモックの返り値がnull
     → テストのセットアップを修正します

自動で実行します...

---

Step 4a: コード修正（対応する・CI修正）

修正が必要な箇所を実装し、意図別にコミットする：

git add <修正ファイル>
git commit -m "fix(<scope>): <コメントの要点を1行で>"
git push origin <branch>

CI失敗の場合は修正前にローカルで再現を試みる（テストコマンドが分かる場合）。

---

Step 4b: Issue作成（スコープ外）

スコープ外のコメントごとに Issue を作成する：

gh issue create \
  --title "feat: <レビューコメントのタイトル>" \
  --body "## 経緯
PR #<番号> のレビューコメントで @<reviewer> から提案されました。

## 提案内容
<コメントの内容をそのまま引用>

## 判断
このPRのスコープ（<Issueのタイトル>）の範囲外のため、別Issueとして追跡します。

## 参考
- 元のレビューコメント: <PRのURL>#pullrequestreview-XXXXXXX"

---

Step 5: コメントへの返信

各スレッドに返信を投稿する：

gh api repos/{owner}/{repo}/pulls/<番号>/reviews \
  --method POST \
  -f commit_id="<headRefOid>" \
  -f event="COMMENT" \
  -f body="<返信サマリー>"

または個別スレッドへの返信：

gh api repos/{owner}/{repo}/pulls/comments/<comment-id>/replies \
  --method POST \
  -f body="<返信文>"

返信のトーン・内容：

• 対応した場合: 「修正しました。〇〇の理由でDateTimeFormatterに変更しました」（コード例添付可）
• 対応しない場合: 「ご指摘ありがとうございます。〇〇の理由で現状のままにします。〈根拠〉」
• Issue化した場合: 「ご提案ありがとうございます。今回のスコープ外のため Issue #<番号> で追跡します。」

不採用の返信は根拠が核心。「好みの問題」では不十分。第一原理・プリモーテムで得た根拠を使う。

---

Step 6: 完了サマリー

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  PR #<番号> 対応完了
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
対応した指摘:
  ✅ SimpleDateFormat → DateTimeFormatter (src/auth/token.ts)
  ✅ CI: testExpiry のNullPointerException を修正

対応しなかった指摘:
  🚫 staticメソッド化 — DI可能性の維持を優先（返信済み）

Issue化したもの:
  📋 feat: エラーメッセージのi18n対応 → Issue #<番号>

作成したコミット:
  - fix(auth): DateTimeFormatterに変更
  - fix(auth): testExpiry のNullPointerExceptionを修正

次のアクション:
  CIの再実行を待つ → /pr-status --wait
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

人間に委ねるケース

以下は自動判定せず確認する：

• レビュアー間で意見が矛盾している（どちらを採用するか判断不能）
• 対応するとアーキテクチャの根本変更が必要（このPRの変更量を大きく超える）
• セキュリティ・データモデルの変更を伴う指摘で影響範囲が不明

その場合は「この指摘は確認が必要です：〈理由〉。対応方針を教えてください。」と1回だけ確認する。