# Pull Requestのサイズ見積もりと分割提案

指定されたタスクに対してPull Requestのサイズを見積もり、必要に応じて分割の提案を行います。

## 実行手順

1. **リポジトリの基本情報収集**
   - コードベースの構造分析（言語、フレームワーク、ディレクトリ構成）
   - 既存のテストとソースコードの比率分析

2. **過去のPull Request履歴分析**
   ```bash
   gh pr list --author @me --state merged --limit 20 --json number,title,additions,deletions,commits
   ```

3. **詳細なPull Request分析**
   - 直近10-20件のPull Requestについて、以下を分析：
     - 変更行数（追加・削除）
     - コミット数（レビュー対応の多さの指標）
     - 変更の性質（機械的変更 vs ロジック変更）

4. **作業量見積もり**
   - ソースコード変更予想行数
   - テスト追加予想行数（既存比率から算出）
   - ドキュメント更新予想行数
   - 設定ファイル・マイグレーション等の付随作業
   - 各フェーズの見積もりには必ずテストコードの行数を含める

5. **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作成を提案し、以下の手順で全体管理を行います：

```bash
# 一時ファイルに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
```

ユーザーの承認後：
```bash
# GitHub Issueを作成
gh issue create --title "[タスク名]" --body-file /tmp/github_issue_draft.md

# 一時ファイルを削除  
rm /tmp/github_issue_draft.md
```

## 注意事項

- 過去のPull Request履歴から学習した傾向を活用
- リポジトリ固有のテスト・ドキュメント慣習を考慮
- レビュー負荷とデプロイリスクを総合的に判断