estimate

見積もり

フェーズ 1：タスクを理解する

引数からタスクの説明を読みます。内容が曖昧すぎて有意義な見積もりができない場合は、先に進む前に確認を求めます。

プロジェクトの背景情報（技術スタック、コーディング規約、アーキテクチャのパターン、見積もりに関するガイドライン）を把握するため、CLAUDE.md を読みます。

タスクが文書化された機能やシステムに関係する場合は、design/gdd/ にある関連設計ドキュメントを読みます。セクションごとに読みます。Grep ツール（パターン ^#、content モード）で必要な見出しを見つけ、offset と limit を指定して該当範囲を Read します。

---

フェーズ 2：影響を受けるコードを調査する

変更が必要なファイルとモジュールを特定します。

• 影響を受けるファイルごとに、Grep でサイズと分岐の数を測定します。Read、Glob、Grep がこのスキルで使用できる唯一のツールであるため、これらの件数を測定値とします。
  • サイズ： Grep pattern="[^[:space:]]" path="[file]" output_mode="count" — 空行以外の行数。
  • 分岐： Grep pattern="(^|[^A-Za-z0-9_])(if|elif|for|foreach|while|match|switch|case|catch)([^A-Za-z0-9_]|$)|&&|[|][|]" path="[file]" output_mode="count" — 分岐またはブール演算子を含む行数。この件数は循環的複雑度の近似値です（コメントや文字列も数えられます）。実測した複雑度としてではなく、必ず近似値として報告します。
  • 依存関係： 各ファイルが取り込む要素（GDScript の preload／load(、C# の using、C++ の #include）と、そのファイルを参照する他のファイルを調べます。
  • Grep で件数を数えられなかったファイル（存在しない、バイナリ、読み取り不可）は省略せず、「注記と前提条件」に記載します。
• 他のシステムとの統合ポイントを特定します。
• 影響を受ける領域に既存のテストカバレッジがあるか確認します。
• 類似する完了済みタスクと過去のベロシティを把握するため、production/sprints/ にある過去のスプリントデータを読みます。 データがない場合は、「注記と前提条件」に「スプリント履歴が見つかりません。この見積もりはチームのベロシティに基づいて調整されていません」と記載します。また、数値に暗黙の余裕を加えるのではなく、信頼度に影響するリスクとして扱います。

---

フェーズ 3：複雑さの要因を分析する

コードの複雑さ：

• 影響を受けるファイルのサイズと分岐数（フェーズ 2 の Grep 件数）
• 依存関係の数と結合度
• コア／エンジンコードに触れるのか、リーフ／機能コードに触れるのか
• 既存のパターンに従えるのか、新しいパターンが必要なのか

スコープ：

• 変更するシステムの数
• 新規コードと既存コードの変更の割合
• 必要となる新しいテストカバレッジの量
• データ移行や設定変更の必要性

リスク：

• 新しい技術や、なじみのないライブラリ
• 不明瞭または曖昧な要件
• 未完了の作業への依存
• システム間統合の複雑さ
• パフォーマンスへの影響度

---

フェーズ 4：見積もりを作成する

## Task Estimate: [Task Name]
Generated: [Date]

### Task Description
[Restate the task clearly in 1-2 sentences]

### Complexity Assessment

| Factor | Assessment | Notes |
|--------|-----------|-------|
| Systems affected | [List] | [Core, gameplay, UI, etc.] |
| Files likely modified | [Count] | [Key files listed below] |
| Size of affected files | [N non-blank lines; M branch lines] | Grep counts; branch lines approximate complexity |
| New code vs modification | [Ratio] | |
| Integration points | [Count] | [Which systems interact] |
| Test coverage needed | [Low / Medium / High] | |
| Existing patterns available | [Yes / Partial / No] | |

**Key files likely affected:**
- `[path/to/file1]` -- [what changes here]

### Effort Estimate

| Scenario | Days | Assumption |
|----------|------|------------|
| Optimistic | [X] | Everything goes right, no surprises |
| Expected | [Y] | Normal pace, minor issues, one round of review |
| Pessimistic | [Z] | Significant unknowns surface, blocked for a day |

**Recommended budget: [Y days]**

### Confidence: [High / Medium / Low]

[Explain which factors drive the confidence level for this specific task.]

### Risk Factors

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|

### Dependencies

| Dependency | Status | Impact if Delayed |
|-----------|--------|-------------------|

### Suggested Breakdown

| # | Sub-task | Estimate | Notes |
|---|----------|----------|-------|
| 1 | [Research / spike] | [X days] | |
| 2 | [Core implementation] | [X days] | |
| 3 | [Testing and validation] | [X days] | |
| | **Total** | **[Y days]** | |

### Notes and Assumptions
- [Key assumption that affects the estimate]
- [Any caveats about scope boundaries]

見積もりは、簡潔な概要とともに出力します。推奨予算、信頼度、最大のリスク要因をそれぞれ 1 つ示します。

このスキルは読み取り専用であり、ファイルへの書き込みは行いません。判定：完了 — 見積もりを作成しました。

---

フェーズ 5：次のステップ

• 信頼度が「低」の場合は、確約する前に期間を区切ったスパイク（/prototype）を推奨します。
• タスクが 10 日を超える場合は、/create-stories を使って小さなストーリーに分割することを推奨します。
• タスクをスケジュールするには、/sprint-plan update を実行して次のスプリントに追加します（デフォルトの最小ワークフローのように、プロジェクトにスプリント計画がない場合は、ブリーフのビルド順に追加します）。

ガイドライン

• 必ず幅を持たせて（楽観／標準／悲観）見積もります。単一の数値は提示しません。
• 推奨予算には、楽観的な見積もりではなく標準的な見積もりを使います。
• 半日単位に丸めます。1 日を超えるタスクを時間単位で見積もると、精度を過剰に装うことになります。
• 見積もりに余裕を暗黙に加えてはいけません。チームが判断できるよう、リスクを明示します。
• アプローチが決まっていない場合や、主要な要件が未確定（TBD）の場合は、信頼度を必ず「低」にします。未決定の判断に基づく幅のある見積もりは、あくまで推測です。