gds-create-story

ストーリーワークフローの作成

目標： 開発エージェントが完璧に実装するために必要な情報をすべて提供する、包括的なストーリーファイルを作成します。

役割： LLM による開発上のミス、見落とし、重大な問題を防ぐストーリーコンテキストエンジンです。

• すべての応答は {communication_language} で行い、言語は必ず {game_dev_experience} に合わせて調整してください
• すべてのドキュメントは {document_output_language} で作成してください
• 目的はエピックから内容をコピーすることではありません。開発エージェントが完璧に実装するために必要な情報をすべて盛り込んだ、包括的で最適化されたストーリーファイルを作成することです
• 防止すべきよくある LLM のミス：既存の仕組みを再発明する、誤ったライブラリを使う、誤ったファイル配置にする、リグレッションを引き起こす、UX を無視する、実装内容が曖昧になる、完了したと偽る、過去の作業から学ばない
• 徹底的な分析が必要です：重要なコンテキストを抽出するために、すべての成果物を十分に分析してください。怠けたり、ざっと目を通すだけで済ませたりしてはいけません。これは開発プロセス全体で最も重要な役割です
• サブプロセスとサブエージェントを活用してください：利用可能であれば、調査用サブエージェント、サブプロセス、または並列処理を使い、複数の成果物を同時に、かつ十分に分析してください
• 質問を保存してください：分析中に質問や確認事項を思いついた場合は、ストーリーを完成させた後に提示できるよう保存してください
• ユーザーによる介入をゼロにしてください：プロセスは、最初のエピック／ストーリーの選択、またはドキュメントの不足を除き、完全に自動化してください

パス

• sprint_status = {implementation_artifacts}/sprint-status.yaml
• epics_file = {planning_artifacts}/epics.md
• gdd_file = {planning_artifacts}/gdd.md
• architecture_file = {planning_artifacts}/architecture.md
• ux_file = {planning_artifacts}/*ux*.md
• story_title = ""（導出できない場合は確認します）
• project_context = **/project-context.md（存在する場合は読み込みます）
• default_output_file = {implementation_artifacts}/{{story_key}}.md

入力ファイル

入力	説明	パスのパターン	読み込み方法
gdd	ゲームデザインドキュメント（フォールバック。通常、エピックファイルに大部分の内容が含まれています）	全体：{planning_artifacts}/*gdd*.md、分割：{planning_artifacts}/*gdd*/*.md	選択的に読み込み
architecture	アーキテクチャ（フォールバック。エピックファイルに関連セクションが含まれているはずです）	全体：{planning_artifacts}/*architecture*.md、分割：{planning_artifacts}/*architecture*/*.md	選択的に読み込み
ux	UX デザイン（フォールバック。エピックファイルに関連セクションが含まれているはずです）	全体：{planning_artifacts}/*ux*.md、分割：{planning_artifacts}/*ux*/*.md	選択的に読み込み
epics	BDD とソースのヒントを含む、拡張版のエピック＋ストーリーファイル	全体：{planning_artifacts}/*epic*.md、分割：{planning_artifacts}/*epic*/*.md	選択的に読み込み
project_context	プロジェクト全体のルール、規約、MCP 設定、サードパーティ製フレームワークの要件	**/project-context.md	全体を読み込み

---

規約

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

起動時

ステップ 1：ワークフローブロックを解決する

次を実行します：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

スクリプトが失敗した場合は、次の 3 つのファイルを base → team → user の順に読み込み、リゾルバーと同じ構造的マージルールを適用して、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 をキーとするテーブルの配列では、一致するエントリを置き換え、新しいエントリを追加します。それ以外の配列はすべて追加します。

ステップ 2：前置ステップを実行する

続行する前に、{workflow.activation_steps_prepend} の各エントリを順番に実行します。

ステップ 3：永続的な事実を読み込む

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

ステップ 4：設定を読み込む

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

• user_name
• communication_language
• document_output_language
• game_dev_experience
• planning_artifacts
• implementation_artifacts
• sprint_status

ステップ 5：ユーザーに挨拶する

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

ステップ 6：後置ステップを実行する

{workflow.activation_steps_append} の各エントリを順番に実行します。

アクティベーションが完了しました。activation_steps_prepend または activation_steps_append が空でなかった場合は、すべてのエントリを順番どおりに実行したことを確認してから続行してください。すべてのアクティベーションステップが完了するまで、メインワークフローを開始しないでください。

実行

ユーザー指定のストーリーパスを解析します。たとえば "1-2-user-auth" の形式から epic_num、story_num、story_title を抽出します ユーザー入力から {{epic_num}}、{{story_num}}、{{story_key}} を設定します ステップ 2a に進みます

自動検出のため、{{sprint_status}} ファイルが存在するか確認します 🚫 スプリントステータスファイルが見つからず、ストーリーも指定されていません 必要な選択肢： 1. sprint-planning を実行してスプリント追跡を初期化する（推奨） 2. 作成するエピックとストーリーの番号を指定する（例："1-2-user-auth"） 3. スプリントステータスがまだ存在しない場合は、ストーリードキュメントへのパスを指定する 選択肢 [1] を選ぶか、エピックとストーリーの番号またはストーリードキュメントへのパスを入力するか、終了するには [q] を入力してください：

<check if="ユーザーが 'q' を選択した">
  <action>停止 — 作業は不要です</action>
</check>

<check if="ユーザーが '1' を選択した">
  <output>まず sprint-planning ワークフローを実行して sprint-status.yaml を作成してください</output>
  <action>停止 — ユーザーは sprint-planning を実行する必要があります</action>
</check>

<check if="ユーザーがエピックとストーリーの番号を指定した">
  <action>ユーザー入力を解析し、epic_num、story_num、story_title を抽出します</action>
  <action>ユーザー入力から {{epic_num}}、{{story_num}}、{{story_key}} を設定します</action>
  <action>ステップ 2a に進みます</action>
</check>

<check if="ユーザーがストーリードキュメントへのパスを指定した">
  <action>ユーザー指定のパスをストーリードキュメントに使用します</action>
  <action>ステップ 2a に進みます</action>
</check>

順序を保持するため、{sprint_status} ファイル全体を最初から最後まで必ず読み込んでください ファイル全体を読み込みます：{{sprint_status}} 内容を一切省略せず、先頭から末尾までのすべての行を読みます development_status セクションをすべて解析します 次の条件に一致する最初のストーリーを（上から下へ順に読み取り）見つけます。 - キーがパターン number-number-name に一致する（例：「1-2-user-auth」） - エピックキー（epic-X）またはレトロスペクティブ（epic-X-retrospective）ではない - ステータス値が「backlog」である

<check if="backlogのストーリーが見つからない">
  <output>📋 sprint-status.yaml に backlog のストーリーが見つかりません

    すべてのストーリーは、すでに作成済み、進行中、または完了済みです。

    **オプション：**
    1. sprint-planning を実行して、ストーリーの追跡情報を更新する
    2. PM エージェントを読み込み、correct-course を実行してストーリーを追加する
    3. 現在のスプリントが完了しているか確認し、レトロスペクティブを実行する
  </output>
  <action>HALT</action>
</check>

<action>見つかったストーリーキーから次の情報を抽出します（例：「1-2-user-authentication」）。
  - epic_num：ダッシュの前にある最初の数字（例：「1」）
  - story_num：最初のダッシュの後にある2番目の数字（例：「2」）
  - story_title：2つ目のダッシュ以降の残りの部分（例：「user-authentication」）
</action>
<action>{{story_id}} = "{{epic_num}}.{{story_num}}" を設定します</action>
<action>後で使用するため、story_key を保存します（例：「1-2-user-authentication」）</action>


<action>{{epic_num}}-1-* パターンを探し、これがエピック {{epic_num}} の最初のストーリーかどうかを確認します</action>
<check if="これがエピック {{epic_num}} の最初のストーリー">
  <action>{{sprint_status}} を読み込み、epic-{{epic_num}} のステータスを確認します</action>
  <action>エピックのステータスが「backlog」の場合 → 「in-progress」に更新します</action>
  <action>エピックのステータスが「contexted」（レガシーステータス）の場合 → 「in-progress」に更新します（後方互換性のため）</action>
  <action>エピックのステータスが「in-progress」の場合 → 変更は不要です</action>
  <check if="エピックのステータスが 'done'">
    <output>🚫 エラー：完了済みのエピックにはストーリーを作成できません</output>
    <output>エピック {{epic_num}} は「done」とマークされています。すべてのストーリーが完了しています。</output>
    <output>作業を追加する必要がある場合は、次のいずれかを行ってください。</output>
    <output>1. sprint-status.yaml でエピックのステータスを手動で「in-progress」に戻す</output>
    <output>2. 追加の作業用に新しいエピックを作成する</output>
    <action>HALT - 続行できません</action>
  </check>
  <check if="エピックのステータスが backlog、contexted、in-progress、done のいずれでもない">
    <output>🚫 エラー：エピックのステータス '{{epic_status}}' は無効です</output>
    <output>エピック {{epic_num}} のステータスが無効です。想定される値：backlog、in-progress、done</output>
    <output>sprint-status.yaml を手動で修正するか、sprint-planning を実行して再生成してください</output>
    <action>HALT - 続行できません</action>
  </check>
  <output>📊 エピック {{epic_num}} のステータスを in-progress に更新しました</output>
</check>

<action>ステップ 2a へ移動します</action>

ファイル全体を読み込みます：{{sprint_status}} 内容を省略せず、先頭から末尾まですべての行を読み取ります development_status セクション全体を解析します

次の条件に一致する最初のストーリーを（上から下へ順に読み取り）見つけます。 - キーがパターン number-number-name に一致する（例：「1-2-user-auth」） - エピックキー（epic-X）またはレトロスペクティブ（epic-X-retrospective）ではない - ステータス値が「backlog」である

sprint-status.yaml に backlog のストーリーが見つかりません

  すべてのストーリーは、すでに作成済み、進行中、または完了済みです。

  **オプション：**
  1. sprint-planning を実行して、ストーリーの追跡情報を更新する
  2. PM エージェントを読み込み、correct-course を実行してストーリーを追加する
  3. 現在のスプリントが完了しているか確認し、レトロスペクティブを実行する
</output>
<action>HALT</action>

見つかったストーリーキー（例：「1-2-user-authentication」）から以下を抽出します。 - epic_num：最初のハイフンより前の数字（例：「1」） - story_num：最初のハイフンの後にある2番目の数字（例：「2」） - story_title：2つ目のハイフンより後の部分（例：「user-authentication」） {{story_id}} = "{{epic_num}}.{{story_num}}" を設定します 後で使用するために story_key を保存します（例：「1-2-user-authentication」）

{{epic_num}}-1-* パターンを探し、これがエピック {{epic_num}} の最初のストーリーかどうかを確認します {{sprint_status}} を読み込み、epic-{{epic_num}} のステータスを確認します エピックのステータスが "backlog" の場合 → "in-progress" に更新します エピックのステータスが "contexted"（旧ステータス）の場合 → "in-progress" に更新します（後方互換性） エピックのステータスが "in-progress" の場合 → 変更は不要です エラー：完了済みのエピックにはストーリーを作成できません エピック {{epic_num}} は 'done' に設定されています。すべてのストーリーが完了しています。 作業を追加する必要がある場合は、次のいずれかを行ってください。 1. sprint-status.yaml でエピックのステータスを手動で 'in-progress' に変更します 2. 追加作業用に新しいエピックを作成します HALT - 続行できません エラー：エピックのステータス '{{epic_status}}' は無効です エピック {{epic_num}} のステータスは無効です。有効な値は backlog、in-progress、done です sprint-status.yaml を手動で修正するか、sprint-planning を実行して再生成してください HALT - 続行できません エピック {{epic_num}} のステータスを in-progress に更新しました

ステップ 2a に進みます

🔬 成果物を徹底的に分析しましょう。将来の開発者のミスを防ぐために重要なステップです。

./discover-inputs.md をすべて読み、記載内容に従ってすべての入力ファイルを読み込みます 利用可能なコンテンツ：{epics_content}、{gdd_content}、{architecture_content}、{ux_content}、 {project_context}

{epics_content} から、エピック {{epic_num}} の完全なコンテキストを抽出します。 エピックの分析： - エピックの目標とビジネス価値 - エピック内のすべてのストーリー（ストーリー間のコンテキスト把握用） - 対象ストーリーの要件、ユーザーストーリーの記述、受け入れ基準 - 技術要件と制約 - 他のストーリー／エピックへの依存関係 - 元のドキュメントを示すソースのヒント 対象ストーリー（{{epic_num}}-{{story_num}}）の詳細を抽出します。 ストーリーの基盤： - ユーザーストーリーの記述（「〜として、〜したい。なぜなら〜だからです」の形式） - 詳細な受け入れ基準（すでに BDD 形式） - このストーリー固有の技術要件 - ビジネス上の背景と価値 - 成功基準 {{previous_story_num}} を見つけます。{implementation_artifacts} を検索し、エピック {{epic_num}} 内で {{story_num}} より小さいストーリー番号のうち、最も大きい番号のストーリーファイルを探します 前のストーリーファイルを読み込みます：{implementation_artifacts}/{{epic_num}}-{{previous_story_num}}-*.md 前のストーリーから得られる知見： - 前のストーリーの開発メモと学び - レビューのフィードバックと必要な修正 - 作成／変更されたファイルとそのパターン - 効果があった／なかったテストの手法 - 発生した問題と解決策 - 確立されたコードパターン 現在のストーリーの実装に影響する可能性のある学びをすべて抽出します

{project_context} を分析し、ストーリーに関係するルールと制約を特定します。 **プロジェクトコンテキストの抽出：** - プロジェクトで必要となるサードパーティのフレームワークとライブラリ - 使用する MCP サーバーの設定と連携 - 従うべきコーディング規約とパターン - プロジェクト全体の制約（特定の API、デプロイ対象など） - このストーリーの実装領域に適用されるルール 抽出したプロジェクトのルールを {{project_rules}} として保存し、ストーリーファイルに埋め込みます。

最近の作業パターンを把握するため、直近5件のコミットタイトルを取得します。 現在のストーリーとの関連性を確認するため、直近1～5件のコミットを分析します。 - 作成・変更されたファイル - 使用されたコードパターンと規約 - 追加・変更されたライブラリ依存関係 - 実装されたアーキテクチャ上の決定 - 使用されたテスト手法 現在のストーリーの実装に役立つ知見を抽出します。

🏗️ アーキテクチャの情報を活用し、開発者が必ず従うべき事項をすべて抽出します。 **アーキテクチャドキュメントの分析：** アーキテクチャの内容を体系的に分析し、ストーリーに関連する要件を特定します。 {architecture_content} 全体を読み込みます。 アーキテクチャのインデックスを読み込み、すべてのアーキテクチャファイルを確認します。 **重要なアーキテクチャ要件の抽出：** アーキテクチャの各セクションについて、このストーリーとの関連性を判断します。 - **技術スタック：** 言語、フレームワーク、ライブラリとそのバージョン - **コード構造：** フォルダー構成、命名規則、ファイルパターン - **API パターン：** サービス構造、エンドポイントのパターン、データコントラクト - **データベーススキーマ：** ストーリーに関係するテーブル、リレーションシップ、制約 - **セキュリティ要件：** 認証パターン、認可ルール - **パフォーマンス要件：** キャッシュ戦略、最適化パターン - **テスト基準：** テストフレームワーク、カバレッジ要件、テストパターン - **デプロイパターン：** 環境設定、ビルドプロセス - **連携パターン：** 外部サービスとの連携、データフロー 開発者が必ず従うべき、ストーリー固有の要件を抽出します。 以前のパターンに優先するアーキテクチャ上の決定を特定します。

📂 変更対象のファイルを読むこと — これを省略すると、実装の失敗やレビューのやり直しにつながります。 アーキテクチャディレクトリの構成から、このストーリーで変更するファイルのうち、UPDATE（NEW ではない）に該当するものをすべて特定します。 該当するUPDATEファイルをそれぞれ最後まで読み込みます。各ファイルについて、開発者向けメモに以下を記録します。 - 現状：現在の動作（状態遷移、API 呼び出し、データ構造、既存の挙動） - このストーリーで変更する内容：変更する具体的なセクションや挙動 - 維持すべき内容：このストーリーによって壊してはならない既存の連携や挙動 ストーリーの実装では、記載された受け入れ基準を満たすだけでなく、システムをエンドツーエンドで動作する状態に保つ必要があります。 既存システムで機能を正しく動作させるために必要な挙動は、ストーリーに明記されているかどうかにかかわらず要件です。 その責任は開発エージェントが負います。

🌐 最新の技術情報を確認し、古い実装を防ぎます。 **ウェブ情報の調査：** 最新バージョンの知識が必要な具体的な技術領域を特定します。

アーキテクチャ分析から、具体的なライブラリ、API、またはフレームワークを特定します 重要なテクノロジーごとに、最新の安定版と主な変更点を調査します： - 最新の API ドキュメントと破壊的変更 - セキュリティの脆弱性や更新 - パフォーマンスの改善や非推奨化 - 現行バージョンにおけるベストプラクティス 外部コンテキストの追加： 開発者に必要な重要な最新情報をストーリーに含めます： - 選定した具体的なライブラリのバージョンと選定理由 - パラメーターと認証を含む API エンドポイント - 最近のセキュリティパッチや考慮事項 - パフォーマンス最適化の手法 - アップグレード時の移行に関する考慮事項

📝 究極のストーリーファイルを作成 — 開発者向けの実装ガイドの決定版です！

template.md から初期化します： {default_output_file} story_header

story_requirements

developer_context_section **開発エージェントのガードレール：** technical_requirements architecture_compliance library_framework_requirements file_structure_requirements testing_requirements

previous_story_intelligence

git_intelligence_summary

latest_tech_information project_context_reference 抽出した {{project_rules}} をすべて含め、プロジェクトコンテキストルールのセクションに記入します。対象には以下が含まれます： - 必須のサードパーティ製フレームワークと、このストーリーでの適用方法 - 開発者が使用する必要のある MCP 統合 - プロジェクト全体に適用される規約と制約 - このストーリーのタスクに関係するドメイン固有のルール story_completion_status

ストーリーのステータスを「ready-for-dev」に設定します 完了メモを追加します：「究極の コンテキストエンジンによる分析が完了しました — 包括的な開発者ガイドを作成しました」

新しく作成したストーリーファイル {default_output_file} を `./checklist.md` に照らして検証し、仕上げる前に必要な修正を適用します ストーリードキュメントを必ず保存します {{sprint_status}} を更新します ファイル全体を読み込み、development_status のすべての項目を確認します {{story_key}} に一致する development_status キーを見つけます 現在のステータスが「backlog」（想定される直前の状態）であることを確認します development_status[{{story_key}}] = "ready-for-dev" に更新します last_updated フィールドを現在の日付に更新します STATUS DEFINITIONS を含むすべてのコメントと構造を保持してファイルを保存します

完了を報告します 🎯 究極の BMad Method ストーリーコンテキストを作成しました、{user_name}！ ストーリーの詳細： - ストーリー ID：{{story_id}} - ストーリーキー：{{story_key}} - ファイル：{{story_file}} - ステータス：ready-for-dev

**次のステップ：**
1. {{story_file}} の包括的なストーリーを確認します
2. 最適化された実装のため、開発エージェント `dev-story` を実行します
3. 完了したら `code-review` を実行します（自動的に完了としてマークされます）
4. 任意：Test Architect モジュールがインストールされている場合は、`dev-story` の後に `/bmad:tea:automate` を実行してガードレールテストを生成します

**これで、開発者は完璧な実装に必要なすべてを揃えました！**

Run: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.