issue-size-estimation

# Issue粒度判定 & コード行数見積もり > **参照元**: 実装ワークフローの粒度判定ロジック --- ## 概要 実装タスクは**200行以下のIssue**を対象とすることを推奨する。 大きなIssueは事前に `/decompose-issue` で分解してから実行すること。 --- ## 粒度判定基準 | 粒度 | 対応 | |------|-------------| | **200行以下** | 直接実装可能 | | **200行超** | `/decompose-issue` で分割してから実装 | | **新規設計** | `/detailed-design-workflow` で設計時に適切な粒度でIssue作成 | --- ## 粒度ルール | 項目 | 基準 | |------|------| | **コード量** | 200行以下 | | **ファイル数** | 1-3ファイル | | **責務** | 単一責務（1つの機能・1つの目的） | | **テスト可能性** | 独立してテスト可能 | | **所要時間目安** | 10-15分で実装完了 | --- ## サイズラベル プロジェクトで以下のラベルを使用することを推奨: | ラベル | 目安行数 | 対応 | |--------|---------|------| | `size/xs` | ~50行 | 直接実装 | | `size/s` | ~100行 | 直接実装 | | `size/m` | ~200行 | 直接実装（境界） | | `size/l` | ~400行 | **要分割** | | `size/xl` | ~800行以上 | **要分割** | --- ## 行数見積もり方法 **優先順位**: 1. Issue labelsから推定（`size/*` ラベル） 2. 設計書のコードブロックから推定 3. Issueタイトル・本文のキーワードから推定 **キーワードベース推定**: | キーワード | 推定行数 | |-----------|---------| | `fix` | ~50行 | | `update` | ~80行 | | `add` | ~100行 | | `refactor` | ~150行 | | `create` | ~150行 | | `implement` | ~200行 | --- ## 分割判定 ```python def should_decompose(issue_id: int) -> bool: """分割が必要かどうか判定""" estimated = estimate_code_lines(issue_id) return estimated > 200 ``` --- ## 大きなIssueを見つけた場合 ```bash # 1. まず分解コマンドを実行 /decompose-issue 8 # 2. 作成されたSubtaskを実装 # (各Subtaskを順次実装) ``` --- ## リトライポリシー | 条件 | アクション | |------|----------| | Issue失敗（1-2回目） | リトライ | | Issue失敗（3回目） | Draft PRを作成、ユーザーに報告 | | 複数Issue並列時 | 失敗したIssueのみ報告、他は継続 |