gds-sprint-planning

スプリント計画ワークフロー

目標： エピックからスプリントのステータス追跡を生成し、現在のストーリーのステータスを検出して、完全な sprint-status.yaml ファイルを作成します。

あなたの役割： スプリントの追跡情報を生成および管理する開発者です。エピックファイルを解析し、ストーリーのステータスを検出して、構造化された sprint-status.yaml を作成します。

パス

• tracking_system = file-system
• project_key = NOKEY
• story_location = {implementation_artifacts}
• story_location_absolute = {implementation_artifacts}
• epics_location = {planning_artifacts}
• epics_pattern = *epic*.md
• status_file = {implementation_artifacts}/sprint-status.yaml

入力ファイル

入力	パス	読み込み方法
エピック	{planning_artifacts}/*epic*.md（全体）または {planning_artifacts}/*epic*/*.md（分割）	FULL_LOAD

コンテキスト

• project_context = **/project-context.md（存在する場合は読み込み）

---

規則

• 裸のパス（例：template.md）はスキルのルートから解決されます。
• {skill-root} は、このスキルがインストールされているディレクトリ（customize.toml がある場所）に解決されます。
• {project-root} は、プロジェクトの作業ディレクトリから開始して親ディレクトリを順にたどり、最初に見つかる _bmad/ を含むフォルダーに解決されます。
• {skill-name} は、スキルディレクトリのベース名に解決されます。

有効化時

Step 1: ワークフローブロックを解決する

実行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

スクリプトが失敗した場合は、ベース → チーム → ユーザーの順に次の3つのファイルを読み込み、リゾルバーと同じ構造マージ規則を適用して、workflow ブロックを自分で解決します。

1. {skill-root}/customize.toml — デフォルト
2. {project-root}/_bmad/custom/{skill-name}.toml — チームによる上書き
3. {project-root}/_bmad/custom/{skill-name}.user.toml — 個人による上書き

存在しないファイルはスキップします。スカラー値は上書きされ、テーブルは再帰的にマージされます。code または id をキーとするテーブルの配列は、一致するエントリを置き換え、新しいエントリを追加します。それ以外の配列はすべて追加されます。

Step 2: prepend ステップを実行する

続行する前に、{workflow.activation_steps_prepend} の各項目を順番に実行します。

Step 3: 永続的な事実を読み込む

{workflow.persistent_facts} の各項目を、ワークフローの実行中に保持する基盤コンテキストとして扱います。file: で始まる項目は {project-root} 配下のパスまたは glob です。参照先の内容を事実として読み込みます。それ以外の項目は、そのまま事実として扱います。

Step 4: 設定を読み込む

{project-root}/_bmad/gds/config.yaml から設定を読み込み、以下を解決します。

• project_name
• user_name
• communication_language
• planning_artifacts
• implementation_artifacts
• date をシステム生成の現在日時として設定

Step 5: ユーザーに挨拶する

{communication_language} で {user_name} に挨拶します。

Step 6: append ステップを実行する

{workflow.activation_steps_append} の各項目を順番に実行します。

有効化が完了します。activation_steps_prepend または activation_steps_append が空でなかった場合は、続行する前に、すべての項目を順番どおりに実行したことを確認してください。すべての有効化ステップが完了するまで、メインワークフローを開始しないでください。

実行

ドキュメントの検出 — エピック全体の読み込み

方針： スプリント計画では、完全なステータス追跡を作成するために、すべてのエピックとストーリーが必要です。

エピックの検出手順：

1. まずドキュメント全体を検索する — epics.md、gds-epics.md、または任意の *epic*.md ファイルを探します
2. 分割版を確認する — ドキュメント全体が見つからない場合は、epics/index.md を探します
3. 分割版が見つかった場合：
   • index.md を読み込み、ドキュメントの構成を把握します
   • インデックスに記載されているすべてのエピックセクションファイル（例：epic-1.md、epic-2.md など）を読み込みます
   • 結合した内容から、すべてのエピックとそのストーリーを処理します
   • これにより、スプリントのステータスを漏れなく網羅できます
4. 優先順位： ドキュメント全体と分割版の両方が存在する場合は、ドキュメント全体を使用します あいまい一致：ドキュメント名には柔軟に対応してください。ユーザーは epics.md、gds-epics.md、user-stories.md など、さまざまな名前を使う場合があります。

プロジェクト全体のパターンと規約を確認するため、{project_context} を読み込みます（存在する場合） {user_name} と {communication_language} でやり取りします {epics_location} で `{epics_pattern}` に一致するすべてのファイルを探します 単一の `epics.md` ファイルの場合もあれば、複数の `epic-1.md`、`epic-2.md` ファイルの場合もあります

見つかった各エピックファイルから、次の情報を抽出します：

• ## Epic 1: や ## Epic 2: のような見出しからエピック番号を抽出します
• ### Story 1.1: User Authentication のような形式から、ストーリー ID とタイトルを抽出します
• ストーリー形式を Epic.Story: Title から kebab-case のキー epic-story-title に変換します

ストーリー ID の変換ルール：

• 元の形式：### Story 1.1: User Authentication
• ピリオドをハイフンに置き換える：1-1
• タイトルを kebab-case に変換する：user-authentication
• 最終キー：1-1-user-authentication

すべてのエピックファイルから、すべてのエピックとストーリーの完全な一覧を作成します

見つかった各エピックについて、次の順序でエントリーを作成します：

1. エピックエントリー - キー：epic-{num}、デフォルトステータス：backlog
2. ストーリーエントリー - キー：{epic}-{story}-{title}、デフォルトステータス：backlog
3. レトロスペクティブエントリー - キー：epic-{num}-retrospective、デフォルトステータス：optional

構造の例：

development_status:
  epic-1: backlog
  1-1-user-authentication: backlog
  1-2-account-management: backlog
  epic-1-retrospective: optional

各ストーリーについて、ファイルを確認して現在のステータスを検出します：

ストーリーファイルの検出：

• 確認先：{story_location_absolute}/{story-key}.md（例：stories/1-1-user-authentication.md）
• 存在する場合 → ステータスを少なくとも ready-for-dev に引き上げます

ステータスの保持ルール：

• 既存の {status_file} があり、より進んだステータスが設定されている場合は、そのステータスを保持します
• ステータスを後退させないでください（例：done を ready-for-dev に変更しない）

ステータスフローの参照：

• エピック：backlog → in-progress → done
• ストーリー：backlog → ready-for-dev → in-progress → review → done
• レトロスペクティブ：optional ↔ done

{status_file} を作成または更新し、次の内容を含めます：

ファイル構造：

# generated: {date}
# last_updated: {date}
# project: {project_name}
# project_key: {project_key}
# tracking_system: {tracking_system}
# story_location: {story_location}

# STATUS DEFINITIONS:
# ==================
# Epic Status:
#   - backlog: Epic not yet started
#   - in-progress: Epic actively being worked on
#   - done: All stories in epic completed
#
# Epic Status Transitions:
#   - backlog → in-progress: Automatically when first story is created (via create-story)
#   - in-progress → done: Manually when all stories reach 'done' status
#
# Story Status:
#   - backlog: Story only exists in epic file
#   - ready-for-dev: Story file created in stories folder
#   - in-progress: Developer actively working on implementation
#   - review: Ready for code review (via Dev's code-review workflow)
#   - done: Story completed
#
# Retrospective Status:
#   - optional: Can be completed but not required
#   - done: Retrospective has been completed
#
# WORKFLOW NOTES:
# ===============
# - Epic transitions to 'in-progress' automatically when first story is created
# - Stories can be worked in parallel if team capacity allows
# - Developer typically creates next story after previous one is 'done' to incorporate learnings
# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)

generated: { date }
last_updated: { date }
project: { project_name }
project_key: { project_key }
tracking_system: { tracking_system }
story_location: { story_location }

development_status:
  # All epics, stories, and retrospectives in order

完全なスプリントステータス YAML を {status_file} に書き込みます 重要：メタデータは2回記述します。1回目はドキュメント用のコメント（#）、2回目は解析用の YAML の key:value フィールドです すべての項目が「エピック、そのストーリー、そのレトロスペクティブ、次のエピック…」の順に並んでいることを確認します

次の検証を実施します：

• エピックファイル内のすべてのエピックが {status_file} に含まれている
• エピックファイル内のすべてのストーリーが {status_file} に含まれている
• すべてのエピックに対応するレトロスペクティブエントリーがある
• エピックファイルに存在しない項目が {status_file} に含まれていない
• すべてのステータス値が有効である（状態遷移の定義に一致する）
• ファイルが有効な YAML 構文である

合計を数えます：

• エピックの合計：{{epic_count}}
• ストーリーの合計：{{story_count}}
• 進行中のエピック：{{in_progress_count}}
• 完了したストーリー：{{done_count}}

{communication_language} で {user_name} に完了サマリーを表示します：

スプリントステータスが正常に生成されました

• ファイルの場所： {status_file}
• エピックの合計： {{epic_count}}
• ストーリーの合計： {{story_count}}
• 進行中のエピック： {{in_progress_count}}
• 完了したストーリー： {{done_count}}

次のステップ：

1. 生成された {status_file} を確認します 2. このファイルを使って開発の進捗を追跡します 3. エージェントは作業中にステータスを更新します 4. このワークフローを再実行して、自動検出されたステータスを更新します 実行：`uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete` — 解決された値が空でない場合は、終了する前の最後のターミナル指示としてそれに従います。

追加ドキュメント

ステータス状態遷移

エピックのステータスフロー：

backlog → in-progress → done

• backlog：エピックはまだ開始されていません
• in-progress：エピックの作業が進行中です（ストーリーの作成または実装中）
• done：エピック内のすべてのストーリーが完了しています

ストーリーのステータスフロー：

backlog → ready-for-dev → in-progress → review → done

• backlog：ストーリーはエピックファイルにのみ存在します
• ready-for-dev：ストーリーファイルが作成されています（例：stories/1-3-plant-naming.md）
• in-progress：開発者が作業中です
• review：コードレビューの準備ができています（Dev のコードレビューワークフロー経由）
• done：完了しています

振り返りのステータス：

optional ↔ done

• optional：実施可能ですが、必須ではありません
• done：完了しています

ガイドライン

1. エピックの開始：最初のストーリーの作業を開始するときに、エピックを in-progress に設定します
2. 通常は順番に進行：通常、ストーリーは順番に作業しますが、並行作業も可能です
3. 並行作業に対応：チームの対応能力に余裕があれば、複数のストーリーを in-progress にできます
4. 完了前にレビュー：ストーリーは done になる前に review を経る必要があります
5. 学びの反映：通常、開発者は前のストーリーが done になってから次のストーリーを作成し、得られた学びを反映します