wasabeef PR レビューコメントへの効率的な対応
Pull Request のレビューコメントを効率的に対応し、エラー分析 3 段階アプローチで根本解決を図ります。
使い方
# レビューコメントの取得と分析
gh pr view --comments
「レビューコメントを優先度別に分類して対応計画を作成してください」
# エラー関連コメントの詳細分析
gh pr checks
「CI エラーを 3 段階アプローチで分析して根本原因を特定してください」
# 修正完了後の品質確認
npm test && npm run lint
「修正が完了したので回帰テストとコード品質をチェックしてください」
基本例
# コメント分類の実行
gh pr view 123 --comments | head -20
"レビューコメントを must/imo/nits/q に分類して対応順序を決めてください"
# エラー情報の収集
npm run build 2>&1 | tee error.log
"ビルドエラーの根本原因を特定し、適切な修正方法を提案してください"
# 修正実装の確認
git diff HEAD~1
"この修正がレビュー指摘事項を適切に解決しているか評価してください"
コメント分類体系
🔴 must: 修正必須
├─ セキュリティ問題
├─ 機能バグ
├─ 設計原則違反
└─ 規約違反
🟡 imo: 改善提案
├─ より良い実装方法
├─ パフォーマンス改善
├─ 可読性向上
└─ リファクタリング提案
🟢 nits: 軽微な指摘
├─ タイポ修正
├─ インデント調整
├─ コメント追加
└─ 命名の微調整
🔵 q: 質問・確認
├─ 実装意図の確認
├─ 仕様の明確化
├─ 設計判断の背景
└─ 代替案の検討
エラー分析 3 段階アプローチ
Stage 1: 情報収集
必須実行
- エラーメッセージの完全取得
- スタックトレースの確認
- 再現条件の特定
推奨実行
- 環境情報の収集
- 最近の変更履歴
- 関連ログの確認
Stage 2: 根本原因分析
- 5 Whys 分析の適用
- 依存関係の追跡
- 環境差異の確認
- 最小再現コードの作成
Stage 3: 解決策実装
- 即座の対処 (ホットフィックス)
- 根本的解決 (本質修正)
- 予防策 (再発防止)
対応フロー
- コメント分析: 優先度別の分類
- 修正計画: 対応順序の決定
- 段階的修正: Critical → High → Medium → Low
- 品質確認: テスト・リント・ビルド
- 進捗報告: 具体的な修正内容の説明
修正後の確認
# 基本チェック
npm test
npm run lint
npm run build
# 回帰テスト
npm run test:e2e
# コード品質
npm run test:coverage
返信テンプレート
修正完了報告
@reviewer ご指摘ありがとうございます。
修正完了いたしました：
- [具体的修正内容]
- [テスト結果]
- [確認方法]
技術判断説明
実装背景：[理由]
検討した代替案：[選択肢と判断根拠]
採用案の利点：[メリット]
注意事項
- 優先度遵守: Critical → High → Medium → Low の順で対応
- テストファースト: 修正前に回帰テスト確認
- 明確な報告: 修正内容と確認方法を具体的に記述
- 建設的対話: 技術的根拠に基づく丁寧なコミュニケーション