sprint-plan

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,story_granularity,workflow

上記で解決済みです。そのまま使用してください。--review は review_mode を上書きします。ブロックがない場合は → .claude/docs/config-resolution.md のデフォルト値が適用されます。

スプリント計画

既存のスプリント

!ls production/sprints/ 2>/dev/null || echo "(no production/sprints/ directory yet)"

このスキルの実行前に解決済みです。Phase 1 で前のスプリントを特定する際に使用し、再度グロブしないでください。

---

Phase 0：引数の解析

モード引数（new、update、または status）を抽出します。

完全なチェックパターンについては .claude/docs/director-gates.md を参照してください。個々のゲート定義は .claude/docs/director-gates/[gate-id].md にあります。起動されたエージェントが自身のゲートファイルを読み取ります。親セッションでは読み取らないでください。

すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います （collaborative では常に質問し、guided では主要な項目のみ質問し、autonomous では記録して続行します。 automation_always_ask カテゴリーでは常に質問します）。

story_granularity — ベロシティに応じて、スプリントあたりに割り当てるストーリー数を設定します。2～4 件は coarse（デフォルト。rigor: minimal 経由）、 6～10 件は balanced（rigor: standard）、 15～25 件は fine です。Ready バックログが範囲より小さい場合は、ストーリーを作り足さず、バックログ全体を計画します。

レビュー モードの確認（ゲート実行前）：

• 上記の解決済みブロックにあるレビュー モードを使用してください（この実行では --review が上書きします）。再解決したり、質問したりしないでください。設定がない場合は modes.rigor に従います。minimal では solo、standard では lean です。
• レビュー モードを書き込まないでください。project.yaml にも、production/review-mode.txt にも書き込まないでください。modes.review_mode は modes.rigor が展開する設定項目のひとつです。project.yaml で固定すると rigor の展開がシャドーイングされ、レガシーファイルはその展開よりも優先されます。そのため、どちらに書き込んでも、ディレクターによるレビューの深度が恒久的に固定されます。単発の変更には --review を使用してください。ユーザーが異なる深度を継続的に適用したい場合は、modes.rigor の変更（/settings modes.rigor=<minimal|standard|full>）を案内するか、意図的に /settings --local modes.review_mode=<full|lean|solo> で固定する方法（project.local.yaml の個人用オーバーライド）を案内してください。

---

フェーズ 1：コンテキストの収集

1. production/milestones/ に現在のマイルストーンがあれば、読み込みます。 このディレクトリに書き込むスキルはありません。.claude/docs/templates/milestone-definition.md をもとに手作業で作成されています。大半のプロジェクトでは存在しないのが通常の状態であり、欠落ではありません。その場合は「マイルストーンは定義されていません — ストーリーのバックログのみをもとに計画します」と記録して続行します。スプリント計画を中断してはならず、スプリントファイルからマイルストーンを推測してはなりません。

2. production/sprints/ に前回のスプリントがあれば、ベロシティと持ち越し項目を把握するために読み込みます。new モードでは、以下のとおりです。

   • 新しいスプリント番号 [N] は、既存スプリント一覧にある最も大きい sprint-NNN.md の番号に 1 を加えた値です（該当ファイルがない場合は 001）。この [N] は、計画書のタイトル、QA 計画のパス、書き込み依頼で使用します。
   • 前回のスプリントにあるストーリーのうち、production/sprint-status.yaml のステータス（なければストーリーファイルの Status 行）で Complete ではないものはすべて、Reason と New Estimate を記入して Carryover テーブルに入れます。新しい Must Have／Should Have／Nice to Have の作業として再度記載してはなりません。

3. 計画対象のストーリーを見つけます。これが実際のバックログであり、このフェーズで欠かせない唯一の入力です。

   Glob production/epics/**/story-*.md
   Grep pattern="^> \*\*Status\*\*" glob="production/epics/**/story-*.md" output_mode="content"
   

   ストーリーは production/epics/[epic-slug]/story-NNN-[slug].md にあります。/create-stories はここに書き込み、/dev-story はここから読み込みます。Ready とマークされたストーリーをもとに計画します。各ストーリーを読むのではなく grep を使用してください。この段階で必要なのはステータスとタイトルであり、本文ではありません。

   glob の結果が空の場合は、「production/epics/ にストーリーが見つかりません。まず /create-stories を実行してください（standard／full では、その前に /create-epics を実行します）。」と伝えます。作業項目をでっち上げて続行してはなりません。存在しないストーリーを参照するスプリント計画は実装できません。判定：ブロック — 計画対象のストーリーがありません。

4. ストーリーが実装する機能について追加のコンテキストを得るため、design/gdd/ の設計ドキュメントを確認します。各ドキュメントはセクション単位で読み込みます。Grep ツールで必要な見出し（パターン ^#、content モード）を探し、offset と limit を指定して該当範囲を Read します。workflow: minimal ではシステムごとの GDD はありません。代わりに design/game-brief.md を使用し、GDD がないことを作業不足と見なしてはなりません。（注：/sprint-plan は minimal では任意です。brief の Build order がすでに計画になっています。）

5. production/risk-register/ にリスク登録簿があれば確認します。上記のマイルストーンと同様、このディレクトリに書き込むスキルはありません。.claude/docs/templates/risk-register-entry.md をもとに、エントリは手作業で作成されています。ディレクトリがない場合は、「リスク登録簿はありません — スプリントの内容のみをもとにリスクを評価します」と一度だけ伝え、リスク評価を黙って省略しないでください。

---

フェーズ 2：出力の生成

new の場合：

以下の形式に従ってスプリント計画を作成し、ユーザーに提示します。 まだ書き込みを求めてはなりません。ファイルの書き込み前にゲートフェーズを実行し、修正が必要になる場合があるためです。ゲートにはプロデューサー実現可能性ゲート（フェーズ 4。full レビューモードでのみ実行され、lean／solo では省略）と、QA 計画チェック（フェーズ 5。すべてのモードで実行）が含まれます。

# Sprint [N] — [Start Date] to [End Date]

## Sprint Goal
[One sentence describing what this sprint achieves toward the milestone]

## Goal Prerequisites
| Needed to show the goal | Status |
|-------------------------|--------|

## Capacity
- Total days: [X]
- Buffer (20%): [Y days reserved for unplanned work]
- Available: [Z days]

## Tasks

### Must Have (Critical Path)
| ID | Task | Agent/Owner | Est. Days | Dependencies | Acceptance Criteria |
|----|------|-------------|-----------|-------------|-------------------|

### Should Have
| ID | Task | Agent/Owner | Est. Days | Dependencies | Acceptance Criteria |
|----|------|-------------|-----------|-------------|-------------------|

### Nice to Have
| ID | Task | Agent/Owner | Est. Days | Dependencies | Acceptance Criteria |
|----|------|-------------|-----------|-------------|-------------------|

## Carryover from Previous Sprint
| Task | Reason | New Estimate |
|------|--------|-------------|

## Risks
| Risk | Probability | Impact | Mitigation |
|------|------------|--------|------------|

## Dependencies on External Factors
- [List any external dependencies]

## Definition of Done for this Sprint
- [ ] All Must Have tasks completed
- [ ] All tasks pass acceptance criteria
- [ ] QA plan exists (`production/qa/qa-plan-[sprint-slug]-[date].md`, from `/qa-plan sprint`)
- [ ] All Logic/Integration stories have passing unit/integration tests
- [ ] Smoke check passed (`/smoke-check sprint`)
- [ ] QA sign-off report: APPROVED or APPROVED WITH CONDITIONS (`/team-qa sprint`)
- [ ] No S1 or S2 bugs in delivered features
- [ ] Design documents updated for any deviations
- [ ] Code reviewed and merged

ゴールの前提条件を確認する

new プランを提示する前に、そのゴールをスプリント終了時までに実際に動作する形で示せるか確認してください。ゴールには、どのストーリーでも作成しないものが必要な場合があります。たとえば、プレイテストには実行するシーンが必要です。この確認では報告のみを行い、進行を妨げることはありません。質問や独自のストーリーは追加しません。

1. ゴールを確定します。 マイルストーンにゴールがある場合はそれを引用し、ない場合は選択したストーリーから1文で記述します。
2. 実演に必要なものを列挙します。 プレイヤーが見たりプレイしたりできるゴール（プレイ可能なループ、エンドツーエンドで動作する機能、プレイテスト）には、それを実行するシーンまたはレベルと、開始設定が必要です。例：project.godot の run/main_scene、Unity の ProjectSettings/EditorBuildSettings.asset にあるシーンリスト、または Unreal の Config/DefaultEngine.ini にある GameDefaultMap。選択したストーリーの受け入れ条件、メモ、依存関係で名前が挙がっていて、選択したストーリーのどれも作成しないファイル、シーン、システムも追加します。実行や表示の対象がないゴール（ロジックとテストのみ）では、何も必要ありません。
3. それぞれを確認します。 プロジェクト内に存在するか、選択したストーリーで作成される場合、その項目は満たされています。シーンはエンジンのシーンファイル（project.yaml の engine.name）で検索します。Godot は *.tscn、Unity は Assets/**/*.unity、Unreal は Content/**/*.umap です。それ以外のものは、ストーリーに記載されたパスまたは名前で検索します。エンジンが設定されていない場合は名前のみで確認し、シーン検索を実行しなかったことを記載します。
4. 「Goal Prerequisites」セクションに記入します。 各項目に exists、built by [story ID]、または missing を記載します。必要なものがない場合は、1行だけで「None: the goal has nothing to run or show」と記載します。欠けている項目はそれぞれ Risks にも記載します。プランを提示する際は、欠けている項目をそれぞれ明示し、ユーザーが選べる3つの対応策を示します。その項目を作成する Ready ストーリーを取り込む（そのストーリーを特定し、それによってスプリントが story_granularity の範囲を超えるか、依存ストーリーが必要になるかを記載する）、/create-stories で先にストーリーを作成する、またはスプリントで実演できることだけを約束するようゴールを書き換える、の3つです。これらは質問としてではなく、プランの一部として提示します。ストーリーの作成を依頼する質問だけを質問として残し、対応を希望するユーザーはその質問への返信で伝えます。不足を報告し、解決しないでください。 欠けている前提条件は、どれほど小さく見えてもこのプランでは欠けたままにします。そのためのタスクを計画したり、その作業を選択したストーリーに含めたりしてはいけません。セットアップとして含めることもできません。その作業には先にストーリーが必要であり、それを担うのが /create-stories です。バックログにないストーリーを追加したり、不足を補うために選択したストーリーの範囲を広げたり、ストーリーファイルを編集したりしてはいけません。

update の場合：

既存のスプリントプランを更新する：

1. production/sprints/ から最新のスプリントプランを読み込みます。
2. production/sprint-status.yaml の現在のステータスとともに、現在のストーリー一覧を提示します。
3. ストーリーの追加、削除、優先順位の変更、または見積もりの変更について、ユーザーに何を変更するか尋ねます。AskUserQuestion を使用して変更内容を確認します。
4. 変更を適用し、改訂したプラン全体を再提示してレビューを受けます。ゴールまたは Must Have ストーリーが変更された場合は、先にゴールの前提条件を再確認します。
5. 改訂したプランに対して、プロデューサーの実現可能性ゲート（フェーズ4）を再実行します。
6. 更新した Markdown プランと YAML を同時に書き込みます（new モードと同じ承認が必要です）。

注：update モードではストーリーのステータスをリセットしません。in-progress または done とマーク済みのストーリーは、そのステータスを維持します。削除または優先順位を自由に変更できるのは、backlog と ready-for-dev のストーリーのみです。

status の場合：

ステータスレポートを生成する：

# Sprint [N] Status -- [Date]

## Progress: [X/Y tasks complete] ([Z%])

### Completed
| Task | Completed By | Notes |
|------|-------------|-------|

### In Progress
| Task | Owner | % Done | Blockers |
|------|-------|--------|----------|

### Not Started
| Task | Owner | At Risk? | Notes |
|------|-------|----------|-------|

### Blocked
| Task | Blocker | Owner of Blocker | ETA |
|------|---------|-----------------|-----|

## Burndown Assessment
[On track / Behind / Ahead]
[If behind: What is being cut or deferred]

## Emerging Risks
- [Any new risks identified this sprint]

---

フェーズ 3：スプリントステータスファイルを準備する

新しいスプリント計画を生成したら、production/sprint-status.yaml の内容も準備します。 これはストーリーのステータスを示す機械可読な信頼できる情報源であり、Markdown の解析を行わずに /sprint-status、/story-done、/help から読み取られます。

まだ YAML を書き込まないでください — 内容はコンテキスト内に保持します。プロデューサーによる実現可能性ゲート（フェーズ 4、full レビューモードのみ）でストーリー一覧が変更される場合があり、QA 計画チェック（フェーズ 5）はすべてのモードで実行されます。両方のファイルはフェーズ 5 の後に、1 回の書き込み承認でまとめて書き込みます。

形式：

# Auto-generated by /sprint-plan. Updated by /story-done and /dev-story.
# DO NOT edit manually — use /story-done to update story status.
#
# Status value mapping (yaml ↔ story file Status field):
#   backlog        ↔  Not Started
#   ready-for-dev  ↔  Ready
#   in-progress    ↔  In Progress
#   review         ↔  In Review
#   done           ↔  Complete
#   blocked        ↔  Blocked

sprint: [N]
goal: "[sprint goal]"
start: "[YYYY-MM-DD]"
end: "[YYYY-MM-DD]"
generated: "[YYYY-MM-DD]"
updated: "[YYYY-MM-DD]"

stories:
  - id: "[epic-story, e.g. 1-1]"
    name: "[story name]"
    file: "[production/epics/[epic-slug]/story-NNN-[slug].md]"   # the real path, verbatim from the Glob above
    priority: must-have        # must-have | should-have | nice-to-have
    status: ready-for-dev      # backlog | ready-for-dev | in-progress | review | done | blocked
    owner: ""
    estimate_days: 0
    blocker: ""
    completed: ""

各ストーリーは、スプリント計画のタスクテーブルから次のように初期化します。

• Must Have タスク → priority: must-have、status: ready-for-dev
• Should Have タスク → priority: should-have、status: backlog
• Nice to Have タスク → priority: nice-to-have、status: backlog
• 持ち越しの行 → そのストーリーの以前の priority と、現在の status

update の場合：既存の sprint-status.yaml を読み取り、変更されていないストーリーのステータスを引き継ぎ、新しいストーリーを追加し、削除されたストーリーを削除します。

---

フェーズ 4：プロデューサーによる実現可能性ゲート

レビューモードの確認 — PR-SPRINT を起動する前に適用します。

• solo → スキップします。注記：「PR-SPRINT をスキップ — Solo モード。」フェーズ 5（QA 計画ゲート）に進みます。
• lean → スキップします（PHASE-GATE ではありません）。注記：「PR-SPRINT をスキップ — Lean モード。」フェーズ 5（QA 計画ゲート）に進みます。
• full → 通常どおり起動します。

スプリント計画を確定する前に、ゲート PR-SPRINT（.claude/docs/director-gates/pr-sprint.md）を使用し、Agent 経由で producer を起動します。

提案されたストーリー一覧（タイトル、見積もり、依存関係）、チームの総作業可能時間（日数または時間）、前のスプリントからの持ち越し、マイルストーンの制約と期限、および目標達成に必要な前提条件で不足しているものを渡します。

プロデューサーの評価を提示します。

UNREALISTIC の場合：ストーリーの選定を見直し（ストーリーを Should Have または Nice to Have に延期）、更新した計画を再提示してから、フェーズ 5 に進みます。

NOT ASSESSED の場合：不足している入力を明示します — REALISTIC ではありません。不足している情報を補って PR-SPRINT を再実行するか、計画のヘッダー（.claude/docs/director-gates.md）に PR-SPRINT の NOT ASSESSED — [missing input] を記録してフェーズ 5 に進み、書き込みを求める際にもその内容を繰り返します。

CONCERNS の場合は、AskUserQuestion を使用します。

• プロンプト：「プロデューサーがこのスプリント計画に懸念を示しました。どのように進めますか？」
• オプション：
  • [A] 計画どおりに進める — リスクを受け入れます
  • [B] スコープを調整する — 一部の Should Have ストーリーを延期する
  • [C] スプリントの期間を延長する

[A] の場合：フェーズ 5 に進みます。 [B] の場合：ストーリー一覧を見直し、更新した計画を再提示してから、フェーズ 5 に進みます。 [C] の場合：スプリントの日程と作業可能時間を調整し、更新した計画を再提示してから、フェーズ 5 に進みます。

プロデューサーの判定への対応後、フェーズ 5 に進みます。書き込みはその最後に行うため、承認するファイルにはフェーズ 5 で追加される内容がすでに反映されています。

---

フェーズ 5：QA 計画ゲート

スプリント計画を確定する前に、このスプリントの QA 計画があるか確認します。

production/qa/qa-plan-*.md に対して Glob を使用します。/qa-plan は qa-plan-[sprint-slug]-[date].md を作成します。ファイル名または内容にこのスプリント番号が含まれているファイルを対象とします。

QA 計画が見つかった場合：スプリント計画の出力に「QA 計画：[path]」と記載して、先に進みます。

QA 計画がない場合：そのまま先に進んではいけません。次の内容を明示します。

「このスプリントには QA 計画がありません。QA 計画のないスプリント計画では、テスト要件が未定義となります。開発者は QA の観点から何をもって「完了」とするのか分からず、QA 計画なしではスプリントは Production → Polish ゲートを通過できません。

実装を始める前に、今すぐ /qa-plan sprint を実行してください。1 回のセッションで、各ストーリーに必要なテストケースの要件が作成されます。」

AskUserQuestion を使用します。

• プロンプト：「このスプリントの QA 計画が見つかりません。どのように進めますか？」
• 選択肢：
  • [A] 今すぐ /qa-plan sprint を実行する — 実装開始前に実行します（推奨）
  • [B] ひとまずスキップする — Production → Polish ゲートで QA 承認がブロックされることを理解しています

下記の書き込み確認を行う前に、この回答を待ちます。この 2 つは別々の質問です。 ここでの回答は、「はい、進めてください」や「計画を書いたら」などであっても、書き込みへの承認にはなりません。 次に書き込みについて質問し、それに「はい」と回答された場合にのみ書き込みます。

[A] の場合：計画に「QA 計画：実装開始前に /qa-plan sprint を実行してください。」と記載します。 [B] の場合：スプリント計画ドキュメントに警告ブロックを追加します。

> ⚠️ **No QA Plan**: This sprint was started without a QA plan. Run `/qa-plan sprint`
> before the last story is implemented. The Production → Polish gate requires a QA
> sign-off report, which requires a QA plan.

計画を書き込む

「スプリント計画を production/sprints/sprint-NNN.md（[N] は 3 桁になるようゼロ埋め）と production/sprint-status.yaml に書き込んでもよろしいですか？」と尋ねます。先ほどの回答が「はい」に聞こえた場合でも、必ず尋ねてください。「はい」の場合、両方のファイルを書き込みます（必要に応じてディレクトリを作成します）。判定：完了 — スプリント計画とステータスファイルを作成しました。「いいえ」の場合： 判定：ブロック — ユーザーが書き込みを拒否しました。

書き込み後、次を追加します。

スコープ確認： このスプリントに、元のエピックのスコープを超えて追加されたストーリーが含まれる場合は、実装開始前に /scope-check [epic] を実行してスコープの逸脱を検出してください。

フェーズ 5 でユーザーが Run /qa-plan sprint now を選んだ場合は、「スプリント計画を書き込みました。次に /qa-plan sprint を実行してから、実装を開始してください。」で締めくくります。

---

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

スプリント計画を書き込み、QA 計画のステータスを確定した後：

• /qa-plan sprint — 実装開始前に必須 — ストーリーごとのテストケースを定義し、開発者が何もない状態からではなく、QA 仕様に沿って実装できるようにします
• /story-readiness [story-file] — ストーリーに着手する前に、準備ができているかを検証します
• /dev-story [story-file] — 最初のストーリーの実装を開始します
• /sprint-status — スプリントの途中で進捗を確認します
• /scope-check [epic] — 実装開始前にスコープの逸脱がないか確認します

レビューモードの設定： すべてのディレクターゲート（プロデューサーによる実現可能性確認、QA レビュー、コードレビュー）では、このスキルの冒頭のブロックで解決されるプロジェクトのレビューモードが適用されます（--review フラグ → project.local.yaml → project.yaml の modes.review_mode → production/review-mode.txt → modes.rigor の展開。標準の厳密さでは lean、最小の厳密さでは solo になります）。このスキルがレビューモードを尋ねたり、設定したりすることはありません。異なる深さを希望するユーザーへの案内先はフェーズ 0 に記載されています。モードは次のいずれかです。

• lean — フェーズゲート以外のディレクターゲートをスキップします（rigor: standard の値）
• full — すべてのディレクターゲートをサブエージェントとして起動します
• solo — 単独の開発者でレビューなしの場合、すべてのゲートの起動を無条件にスキップします

project.yaml の modes.review_mode が主な情報源です。production/review-mode.txt はレガシーなフォールバックです。/sprint-plan、/story-readiness、/story-done およびその他のゲートを使用するスキルは、起動時にどちらも読み込みます。