bmad-create-story

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

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

あなたの役割: LLM 開発者のミス、漏れ、破綻を防ぐストーリーコンテキストエンジンです。

• すべての応答は {communication_language} で行い、すべてのドキュメントは {document_output_language} で生成してください
• あなたの目的はエピックからのコピーではありません — DEV エージェントが完璧な実装に必要とするすべてを提供する、包括的で最適化されたストーリーファイルを作成することです
• 防ぐべき一般的な LLM のミス: 車輪の再発明、誤ったライブラリ、誤ったファイル配置、リグレッションの発生、UX の無視、曖昧な実装、完了に関する虚偽の報告、過去の作業からの学習不足
• 徹底的な分析が必要です: 重要なコンテキストを抽出するためにすべての成果物を徹底的に分析しなければなりません — 怠けたり流し読みしたりしないでください！これは開発プロセス全体で最も重要な機能です！
• サブプロセスとサブエージェントを活用してください: 利用可能であれば、リサーチサブエージェント、サブプロセス、または並列処理を使用して、異なる成果物を同時にかつ徹底的に分析してください
• 質問は保存してください: 分析中に質問や確認事項を思いついた場合は、完全なストーリーを書き終えた後の最後まで保存してください
• ユーザーの介入はゼロ: 最初のエピック/ストーリーの選択やドキュメントの欠落を除き、プロセスは完全に自動化されるべきです

サブエージェントは、その機能が利用可能な場合、このワークフローの重要な一部です。ワークフローのステップの指示に従って使用してください。 それらを実行するためにユーザーからの明示的な指示が必要な場合は、ワークフロー実行全体に対して今一度だけ確認してください。

規約

• ベアパス（例: discover-inputs.md）はスキルルートから解決されます。
• {skill-root} はこのスキルのインストールディレクトリ（customize.toml がある場所）に解決されます。
• {project-root} プレフィックス付きのパスは、プロジェクトの作業ディレクトリから解決されます。
• {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/bmm/config.yaml から設定を読み込み、以下を解決してください:

• project_name、user_name
• communication_language、document_output_language
• user_skill_level
• planning_artifacts、implementation_artifacts
• date はシステム生成の現在の日時として

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

{communication_language} で話しながら、{user_name} に挨拶してください。

非推奨: bmad-build が現在の公式な実装方法です。名前を明示して呼び出された場合にのみこれを使用してください。

ステップ 6: 末尾ステップを実行する

{workflow.activation_steps_append} の各エントリを順番に実行してください。

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

パス

• sprint_status = {implementation_artifacts}/sprint-status.yaml
• epics_file = {planning_artifacts}/epics.md
• prd_file = {planning_artifacts}/prd.md
• architecture_file = {planning_artifacts}/architecture.md
• ux_file = {planning_artifacts}/*ux*.md
• story_title = ""（導出できない場合は聞き出します）
• default_output_file = {implementation_artifacts}/{{story_key}}.md

入力ファイル

入力	説明	パスパターン	読み込み戦略
prd	PRD（フォールバック - ほとんどの内容は epics ファイルにあるはずです）	whole: {planning_artifacts}/*prd*.md、sharded: {planning_artifacts}/*prd*/*.md	SELECTIVE_LOAD
architecture	アーキテクチャ（フォールバック - 関連するセクションは epics ファイルにあるはずです）	whole: {planning_artifacts}/*architecture*.md、sharded: {planning_artifacts}/*architecture*/*.md	SELECTIVE_LOAD
ux	UX デザイン（フォールバック - 関連するセクションは epics ファイルにあるはずです）	whole: {planning_artifacts}/*ux*.md、sharded: {planning_artifacts}/*ux*/*.md	SELECTIVE_LOAD
epics	BDD とソースのヒントを含む拡張された epics+stories ファイル	whole: {planning_artifacts}/*epic*.md、sharded: {planning_artifacts}/*epic*/*.md	SELECTIVE_LOAD

実行

ユーザーが指定したストーリーパスを解析する: "1-2-user-auth" のような形式から epic_num、story_num、story_title を抽出します ユーザー入力から {{epic_num}}、{{story_num}}、{{story_key}} を設定します ステップ 2a へ進みます

自動検出のために {{sprint_status}} ファイルが存在するか確認します 🚫 スプリントステータスファイルが見つからず、ストーリーも指定されていません 必須のオプション: 1. sprint-planning を実行してスプリントトラッキングを初期化する（推奨） 2. 作成する特定の epic-story 番号を指定する（例: "1-2-user-auth"） 3. スプリントステータスがまだ存在しない場合は、ストーリードキュメントへのパスを指定する オプション [1] を選択するか、epic-story 番号、ストーリードキュメントへのパスを指定するか、[q] で終了します:

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

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

<check if="ユーザーが epic-story 番号を指定した">
  <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>

順序を保つため、COMPLETE な {sprint_status} ファイルを最初から最後まで必ず読む必要があります ファイル全体を読み込みます: {{sprint_status}} 最初から最後まですべての行を読み込みます - 内容を一切スキップしないでください development_status セクションを完全に解析します

<action>最初のストーリー（上から下へ順に読んで）を見つけます。条件は次のとおりです:
  - キーがパターンに一致する: number-number-name（例: "1-2-user-auth"）
  - epic キー（epic-X）やレトロスペクティブ（epic-X-retrospective）ではない
  - ステータス値が "backlog" と等しい
</action>

<check if="バックログのストーリーが見つからない">
  <output>📋 sprint-status.yaml にバックログのストーリーが見つかりませんでした

    すべてのストーリーはすでに作成済み、進行中、または完了のいずれかです。
    **オプション:**
    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 {{epic_num}} の最初のストーリーかどうかを確認します</action>
<check if="this is first story in epic {{epic_num}}">
  <action>{{sprint_status}} をロードし、epic-{{epic_num}} のステータスを確認します</action>
  <action>epic のステータスが "backlog" の場合 → "in-progress" に更新します</action>
  <action>epic のステータスが "contexted"（レガシーステータス）の場合 → "in-progress" に更新します（後方互換性）</action>
  <action>epic のステータスが "in-progress" の場合 → 変更は不要です</action>
  <check if="epic status is 'done'">
    <output>🚫 エラー: 完了した epic ではストーリーを作成できません</output>
    <output>Epic {{epic_num}} は 'done' としてマークされています。すべてのストーリーが完了しています。</output>
    <output>さらに作業を追加する必要がある場合は、次のいずれかを行ってください:</output>
    <output>1. sprint-status.yaml で epic のステータスを手動で 'in-progress' に戻す</output>
    <output>2. 追加作業用に新しい epic を作成する</output>
    <action>HALT - 続行できません</action>
  </check>
  <check if="epic status is not one of: backlog, contexted, in-progress, done">
    <output>🚫 エラー: 無効な epic ステータス '{{epic_status}}'</output>
    <output>Epic {{epic_num}} のステータスが無効です。期待値: backlog、in-progress、または done</output>
    <output>sprint-status.yaml を手動で修正するか、sprint-planning を実行して再生成してください</output>
    <action>HALT - 続行できません</action>
  </check>
  <output>📊 Epic {{epic_num}} のステータスを in-progress に更新しました</output>
</check>

<action>ステップ 2a に進みます</action>

ファイル全体をロードします: {{sprint_status}} 最初から最後まで ALL 行を読み取ります - コンテンツを一切スキップしないでください development_status セクションを完全に解析します

以下の条件を満たす最初のストーリーを（上から下へ順に読んで）見つけます: - キーがパターンに一致する: number-number-name（例: "1-2-user-auth"） - epic キー（epic-X）またはレトロスペクティブ（epic-X-retrospective）ではない - ステータス値が "backlog" に等しい

sprint-status.yaml にバックログのストーリーが見つかりませんでした

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

  **オプション:**
  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 {{epic_num}} の最初のストーリーかどうかを {{epic_num}}-1-* パターンを探して確認する {{sprint_status}} を読み込み、epic-{{epic_num}} のステータスを確認する epic のステータスが「backlog」の場合 → 「in-progress」に更新する epic のステータスが「contexted」（レガシーステータス）の場合 → 「in-progress」に更新する（後方互換性） epic のステータスが「in-progress」の場合 → 変更は不要 エラー: 完了した epic にはストーリーを作成できません Epic {{epic_num}} は「done」としてマークされています。すべてのストーリーが完了しています。 さらに作業を追加する必要がある場合は、次のいずれかを行ってください: 1. sprint-status.yaml で epic のステータスを手動で「in-progress」に戻す 2. 追加作業用に新しい epic を作成する HALT - 続行できません エラー: 無効な epic ステータス「{{epic_status}}」 Epic {{epic_num}} のステータスが無効です。期待値: backlog、in-progress、または done sprint-status.yaml を手動で修正するか、sprint-planning を実行して再生成してください HALT - 続行できません Epic {{epic_num}} のステータスを in-progress に更新しました

ステップ 2a へ進む

🔬 徹底的な成果物分析 - ここで将来の開発者のミスを防ぎます！

./discover-inputs.md を最後まで読んで従い、すべての入力ファイルを読み込む 利用可能なコンテンツ: {epics_content}、{prd_content}、{architecture_content}、{ux_content}、およびアクティベーション時に persistent_facts を介して読み込まれたファクト（ユーザーがオプトインしていない限り空です）。

{epics_content} から Epic {{epic_num}} の完全なコンテキストを抽出する: EPIC 分析: - Epic の目的とビジネス価値 - ストーリー横断のコンテキストのための、この epic 内のすべてのストーリー - 対象ストーリーの要件、ユーザーストーリー 記述、受け入れ基準 - 技術要件と制約 - 他のストーリー/epic への依存関係 - 元のドキュメントを指すソースヒント 対象ストーリー（{{epic_num}}-{{story_num}}）の詳細を抽出する: ストーリーの基盤: - ユーザーストーリー記述 （As a、I want、so that） - 詳細な受け入れ基準（すでに BDD 形式） - このストーリー固有の技術要件 - ビジネスコンテキストと価値 - 成功基準 {{previous_story_num}} を探す: {implementation_artifacts} をスキャンして、epic {{epic_num}} 内で {{story_num}} より小さい最大のストーリーナンバーを持つストーリーファイルを探す 前のストーリーファイルを読み込む: {implementation_artifacts}/{{epic_num}}-{{previous_story_num}}-*.md 前のストーリーからの知見: - 前のストーリーからの開発メモと学び - レビューフィードバックと必要な修正 - 作成/変更されたファイルとその パターン - うまくいった/いかなかったテストアプローチ - 遭遇した問題と見つかった解決策 - 確立されたコードパターン 現在のストーリーの実装に影響を与える可能性のあるすべての学びを抽出する

直近の作業パターンを把握するために、最後の 5 件のコミットタイトルを取得する 現在のストーリーとの関連性について、直近 1〜5 件のコミットを分析する: - 作成/変更されたファイル - 使用されたコードパターンと規約 - 追加/変更されたライブラリ依存関係 - 実装されたアーキテクチャ上の決定 - 使用されたテストアプローチ 現在のストーリーの実装に役立つ実践的なインサイトを抽出する 🏗️ アーキテクチャインテリジェンス - 開発者が必ず従わなければならないすべてを抽出します! アーキテクチャドキュメント分析: ストーリーに関連する要件について、アーキテクチャの内容を体系的に 分析します:

完全な {architecture_content} を読み込みます アーキテクチャのインデックスを読み込み、すべてのアーキテクチャファイルをスキャンします **重要なアーキテクチャの抽出:** 各アーキテクチャセクションについて、 このストーリーに関連するかどうかを判断します: - **技術スタック:** バージョンを含む言語、フレームワーク、ライブラリ - **コード構造:** フォルダー構成、命名規則、ファイルパターン - **API パターン:** サービスの構造、エンドポイント パターン、データコントラクト - **データベーススキーマ:** ストーリーに関連するテーブル、リレーションシップ、制約 - **セキュリティ要件:** 認証パターン、認可ルール - **パフォーマンス要件:** キャッシュ戦略、最適化パターン - **テスト 標準:** テストフレームワーク、カバレッジの期待値、テストパターン - **デプロイパターン:** 環境構成、ビルド プロセス - **統合パターン:** 外部サービス統合、データフロー 開発者が必ず従わなければならない ストーリー固有の要件を抽出します 以前のパターンを上書きするアーキテクチャ上の決定を特定します

📂 変更対象のファイルを読み込む — これを省略することが、実装の失敗とレビューサイクルの主な原因です アーキテクチャのディレクトリ構造から、このストーリーが触れる UPDATE (NEW ではない) とマークされたすべてのファイルを特定します 関連する各 UPDATE ファイルを完全に読み込みます。それぞれについて、開発メモに以下を記録します: - 現在の状態: 現在何を行っているか (ステートマシン、API 呼び出し、データ形状、既存の動作) - このストーリーが変更する内容: 変更される特定のセクションまたは動作 - 保持しなければならないもの: ストーリーが壊してはならない既存の相互作用と動作 ストーリーの実装は、システムをエンドツーエンドで動作する状態に保たなければなりません — 単に記載された AC を 満たすだけでは不十分です。既存のシステムで機能が正しく動作するために必要な動作は、 ストーリーに明示的に書かれているかどうかにかかわらず要件です。これを担うのは開発エージェントです。

🌐 最新の技術知識を確保する - 古い実装を防ぎます! **Web インテリジェンス:** 最新バージョンの知識が必要な 特定の技術分野を特定します:

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

📝 究極のストーリーファイルを作成する - 開発者の実装マスターガイドです!

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

story_requirements

developer_context_section **DEV AGENT GUARDRAILS:** technical_requirements architecture_compliance library_framework_requirements file_structure_requirements testing_requirements

previous_story_intelligence

git_intelligence_summary

latest_tech_information

project_context_reference

story_completion_status

ストーリーのステータスを "ready-for-dev" に設定します 完了メモを追加します: "Ultimate context engine analysis completed - comprehensive developer guide created"

新しく作成されたストーリーファイル {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 を含むすべてのコメントと構造を保持したままファイルを保存します

完了を報告します 🎯 ULTIMATE BMad Method STORY CONTEXT CREATED, {user_name}!

**ストーリーの詳細:**
- Story ID: {{story_id}}
- Story Key: {{story_key}}
- ファイル: {{story_file}}
- ステータス: ready-for-dev

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

**開発者は、完璧な実装に必要なすべてを手にしています！**

実行します: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete` — 解決された値が空でない場合、終了する前に最終的な終端命令としてそれに従います。