5.0 KiB
5.0 KiB
Pull Requestのサイズ見積もりと分割提案
指定されたタスクに対してPull Requestのサイズを見積もり、必要に応じて分割の提案を行います。
実行手順
-
リポジトリの基本情報収集
- コードベースの構造分析（言語、フレームワーク、ディレクトリ構成）
- 既存のテストとソースコードの比率分析
-
過去のPull Request履歴分析
gh pr list --author @me --state merged --limit 20 --json number,title,additions,deletions,commits -
詳細なPull Request分析
- 直近10-20件のPull Requestについて、以下を分析：
- 変更行数（追加・削除）
- コミット数（レビュー対応の多さの指標）
- 変更の性質（機械的変更 vs ロジック変更）
- 直近10-20件のPull Requestについて、以下を分析：
-
作業量見積もり
- ソースコード変更予想行数
- テスト追加予想行数（既存比率から算出）
- ドキュメント更新予想行数
- 設定ファイル・マイグレーション等の付随作業
- 各フェーズの見積もりには必ずテストコードの行数を含める
-
Pull Request分割アドバイス
- 500行以下：単一Pull Request推奨
- 500-1000行：分割可能性検討
- 1000行超：分割強く推奨
- アーキテクチャ考慮した分割順序提案
分析ポイント
変更の性質分類
- 機械的変更：一括置換、フォーマット調整、import整理等
- ファイル数多くてもレビュー負荷低
- ロジック変更：新規実装、既存ロジック修正
- 少ない行数でもレビュー負荷高
分割戦略
- レイヤー別分割：DB層 → API層 → UI層
- 段階別分割：設定変更 → 実装 → テスト
- 依存関係考慮：破壊的変更の分離、マイグレーション等
避けるべき分割パターン
以下のような分割は絶対に避けてください：
- フェーズ1: 機能実装のみ
- フェーズ2: 統合作業
- フェーズ3: テスト追加
理由：
- テストのない実装コードをレビューすることは非常に困難
- 実装の正しさを検証する手段がない
- 後からテストを追加する際に実装の問題が発覚するリスク
推奨される分割方法：
- 各フェーズで実装とテストをセットで含める
- 各Pull Requestが独立してマージ可能な状態を保つ
- テストコードの行数も含めて見積もりを行う
リスク評価
- コミット数が多い過去Pull Request → レビュー対応が多い可能性
- 複雑なビジネスロジック変更 → 慎重な分割が必要
- 本番への影響度 → デプロイリスク考慮
出力形式
単一Pull Request推奨の場合
## 見積もり結果
- 予想ソースコード変更：XXX行
- 予想テスト追加：XXX行
- 予想ドキュメント更新：XXX行
- 合計予想変更行数：XXX行
## 分割提案
単一Pull Requestで実装することを推奨します。
[推奨理由と実装時の注意点]
複数Pull Request分割推奨の場合
Claude Codeのようなエージェントが全体のコンテキストを把握しやすくするため、GitHub Issue作成を提案し、以下の手順で全体管理を行います：
# 一時ファイルにIssue内容を作成
cat > /tmp/github_issue_draft.md << 'EOF'
# [タスク名]
## 背景・課題
[やりたいことの背景とコンテキストを記載]
## 実装概要
合計予想変更行数：XXX行
[トータルで必要な修正内容の概要]
上記の予想変更行数に基づき、レビュー負荷とデプロイリスクを考慮して以下のフェーズに分割することを推奨します。
## 実装フェーズ
### フェーズ1: [第1段階の内容]
- [具体的な作業内容]
- 予想変更行数：XXX行（実装：XXX行、テスト：XXX行）
- 含まれるテスト: [この段階で追加されるテストの説明]
### フェーズ2: [第2段階の内容]
- [具体的な作業内容]
- 予想変更行数：XXX行（実装：XXX行、テスト：XXX行）
- 含まれるテスト: [この段階で追加されるテストの説明]
### フェーズ3: [第3段階の内容]
- [具体的な作業内容]
- 予想変更行数：XXX行（実装：XXX行、テスト：XXX行）
- 含まれるテスト: [この段階で追加されるテストの説明]
## 注意事項
- [実装時の注意点]
- [依存関係やリスク]
EOF
echo "以下の内容でGitHub Issueを作成しますか？"
cat /tmp/github_issue_draft.md
ユーザーの承認後：
# GitHub Issueを作成
gh issue create --title "[タスク名]" --body-file /tmp/github_issue_draft.md
# 一時ファイルを削除
rm /tmp/github_issue_draft.md
注意事項
- 過去のPull Request履歴から学習した傾向を活用
- リポジトリ固有のテスト・ドキュメント慣習を考慮
- レビュー負荷とデプロイリスクを総合的に判断