bmad-dev-story

Dev Story ワークフロー

目標: コンテキストが埋められたストーリー仕様ファイルに従って、ストーリー実装を実行します。

あなたの役割: ストーリーを実装する開発者。

• すべての応答を {communication_language} で伝え、その言語は {user_skill_level} に合わせて調整しなければなりません（MUST）
• すべてのドキュメントを {document_output_language} で生成します
• ストーリーファイルを変更するのは次の領域のみです: YAML frontmatter の baseline_commit、タスク/サブタスクのチェックボックス、Dev Agent Record（デバッグログ、完了ノート）、ファイルリスト、変更履歴、およびステータス
• すべてのステップを正確な順序で実行します。ステップをスキップしないでください
• 「マイルストーン」「大きな進捗」「セッションの区切り」を理由に絶対に停止しないでください。HALT 条件が発生するか、ユーザーが別の指示を出さない限り、ストーリーが完了する（すべての AC を満たし、すべてのタスク/サブタスクがチェックされる）まで単一の実行を続けてください。
• HALT 条件が該当しない限り、「次のセッション」を予定したり、レビューのための一時停止を要求したりしないでください。完了を判断するのはステップ 9 のみです。
• ユーザーのスキルレベル（{user_skill_level}）は会話スタイルのみに影響し、コードの更新には影響しません。

規約

• 素のパス（例: steps/step-01-init.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
• implementation_artifacts
• date をシステム生成の現在の日時として
• project_context = **/project-context.md（存在する場合は読み込む）

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

{user_name} に、{communication_language} で話しかけて挨拶します。

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

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

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

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

パス

• story_file = ``（明示的なストーリーパス。空の場合は自動検出）
• sprint_status = {implementation_artifacts}/sprint-status.yaml

実行

{communication_language} ですべての応答を communicate し、言語は {user_skill_level} に合わせて MUST 調整してください {document_output_language} ですべてのドキュメントを generate してください ストーリーファイルを変更できるのは次の領域のみです: YAML frontmatter `baseline_commit`、タスク/サブタスクのチェックボックス、Dev Agent Record (Debug Log、Completion Notes)、File List、 Change Log、および Status すべてのステップを正確な順序で execute してください。ステップを skip しないでください 「マイルストーン」、「大幅な進捗」、または「セッションの区切り」を理由に絶対に停止しないでください。HALT 条件が発生するか、ユーザーが 別の指示を与えない限り、ストーリーが COMPLETE になるまで (すべての AC が満たされ、すべてのタスク/サブタスクがチェックされるまで) 単一の実行で続行してください。 HALT 条件が適用されない限り、「次のセッション」を schedule したり、レビューの一時停止を request したりしないでください。完了を決定するのはステップ 9 のみです。 ユーザーのスキルレベル ({user_skill_level}) は会話スタイルのみに影響し、コードの更新には影響しません。 {{story_path}} を直接使用する COMPLETE なストーリーファイルを読む ファイル名またはメタデータから story_key を抽出する

<check if="{{sprint_status}} ファイルが存在する">
  <critical>順序を保つため、COMPLETE な sprint-status.yaml ファイルを最初から最後まで MUST 読んでください</critical>
  <action>FULL ファイルをロードする: {{sprint_status}}</action>
  <action>最初から最後まですべての行を読む - 内容を skip しないでください</action>
  <action>ストーリーの順序を理解するため、development_status セクションを完全に parse する</action>

  <action>FIRST ストーリー (上から下へ順に読んで) を見つける。条件:
    - キーがパターンに一致: number-number-name (例: "1-2-user-auth")
    - epic キー (epic-X) またはレトロスペクティブ (epic-X-retrospective) ではない
    - ステータス値が "ready-for-dev" と等しい
  </action>

  <check if="ready-for-dev または in-progress のストーリーが見つからない">
    <output>📋 sprint-status.yaml に ready-for-dev のストーリーが見つかりませんでした

      **現在のスプリントステータス:** {{sprint_status_summary}}

      **どうしますか?**
      1. `create-story` を実行して、エピックから包括的なコンテキストを持つ次のストーリーを作成する
      2. `*validate-create-story` を実行して、開発前に既存のストーリーを改善する (推奨される品質チェック)
      3. 開発する特定のストーリーファイルを指定する (完全なパスを提供してください)
      4. {{sprint_status}} ファイルを確認して現在のスプリントステータスを確認する

      💡 **ヒント:** `ready-for-dev` のストーリーは検証されていない可能性があります。品質チェックのため、まず `validate-create-story` を実行することを検討してください。
    </output>
    <ask>オプション [1]、[2]、[3]、または [4] を選ぶか、ストーリーファイルのパスを指定してください:</ask>

    <check if="ユーザーが '1' を選ぶ">
      <action>HALT - create-story を実行して次のストーリーを作成する</action>
    </check>

    <check if="ユーザーが '2' を選ぶ">
      <action>HALT - validate-create-story を実行して既存のストーリーを改善する</action>
    </check>

    <check if="ユーザーが '3' を選ぶ">
      <ask>開発するストーリーファイルのパスを提供してください:</ask>
      <action>ユーザーが提供したストーリーパスを {{story_path}} として保存する</action>
      <goto anchor="task_check" />
    </check>

    <check if="ユーザーが '4' を選ぶ">
      <output>{{sprint_status}} をロードして詳細なステータスを確認します...</output>
      <action>詳細なスプリントステータス分析を表示する</action>
      <action>HALT - ユーザーはスプリントステータスを確認してストーリーパスを提供できます</action>
    </check>

    <check if="ユーザーがストーリーファイルのパスを提供する">
      <action>ユーザーが提供したストーリーパスを {{story_path}} として保存する</action>
      <goto anchor="task_check" />
    </check>
  </check>
</check>


<check if="{{sprint_status}} ファイルが存在しない">
  <action>{implementation_artifacts} 内でストーリーを直接検索する</action>
  <action>ファイル内で "ready-for-dev" ステータスのストーリーを見つける</action>
  <action>パターン *-*-*.md に一致するストーリーファイルを探す</action>
  <action>各候補のストーリーファイルを読み込み、Status セクションを確認する</action>

  <check if="ストーリーファイル内に ready-for-dev のストーリーが見つからない">
    <output>📋 ready-for-dev のストーリーが見つかりませんでした

      **利用可能なオプション:**
      1. `create-story` を実行して、エピックから包括的なコンテキストを伴う次のストーリーを作成する
      2. `*validate-create-story` を実行して、既存のストーリーを改善する
      3. 開発するストーリーを指定する
    </output>
    <ask>どのように進めますか？オプション [1]、[2]、または [3] を選択してください:</ask>

    <check if="ユーザーが '1' を選択">
      <action>HALT - create-story を実行して次のストーリーを作成する</action>
    </check>

    <check if="ユーザーが '2' を選択">
      <action>HALT - validate-create-story を実行して既存のストーリーを改善する</action>
    </check>

    <check if="ユーザーが '3' を選択">
      <ask>開発したいストーリーが不明です。ストーリーファイルの完全なパスを指定してください:</ask>
      <action>ユーザーが指定したストーリーパスを {{story_path}} として保存する</action>
      <action>指定されたストーリーファイルで続行する</action>
    </check>
  </check>

  <check if="ファイル内に ready-for-dev のストーリーが見つかった">
    <action>検出したストーリーファイルを使用し、story_key を抽出する</action>
  </check>
</check>

<action>見つかった story_key（例: "1-2-user-authentication"）を後のステータス更新のために保存する</action>
<action>{implementation_artifacts} 内で story_key パターン {{story_key}}.md に一致するストーリーファイルを見つける</action>
<action>検出したパスからストーリーファイル全体を読み込む</action>

<anchor id="task_check" />

<action>セクションを解析する: Story、Acceptance Criteria、Tasks/Subtasks、Dev Notes、Dev Agent Record、File List、Change Log、Status</action>

<action>ストーリーファイルの Dev Notes セクションから包括的なコンテキストを読み込む</action>
<action>Dev Notes から開発者向けのガイダンスを抽出する: アーキテクチャ要件、過去の学び、技術仕様</action>
<action>拡張されたストーリーコンテキストを使用して、実装の判断とアプローチに反映する</action>

<action>Tasks/Subtasks 内で最初の未完了タスク（未チェック [ ]）を特定する</action>

<action if="未完了のタスクがない">
  <goto step="9">完了シーケンス</goto>
</action>
<action if="ストーリーファイルにアクセスできない">HALT: "ストーリーファイルにアクセスできないため、ストーリーを開発できません"</action>
<action if="未完了のタスクまたはサブタスクの要件が曖昧">ユーザーに明確化を求めるか HALT</action>

実装に反映するため、利用可能なすべてのコンテキストを読み込む

<action>コーディング標準とプロジェクト全体のパターンのために {project_context} を読み込む（存在する場合）</action>
<action>セクションを解析する: Story、Acceptance Criteria、Tasks/Subtasks、Dev Notes、Dev Agent Record、File List、Change Log、Status</action>
<action>ストーリーファイルの Dev Notes セクションから包括的なコンテキストを読み込む</action>
<action>Dev Notes から開発者向けのガイダンスを抽出する: アーキテクチャ要件、過去の学び、技術仕様</action>
<action>拡張されたストーリーコンテキストを使用して、実装の判断とアプローチに反映する</action>
<output>✅ **コンテキストを読み込みました**
  ストーリーとプロジェクトのコンテキストが実装に利用可能です
</output>

これが新規の開始なのか、コードレビュー後の継続なのかを判断する

<action>ストーリーファイルに "Senior Developer Review (AI)" セクションが存在するか確認する</action>
<action>Tasks/Subtasks の下に "Review Follow-ups (AI)" サブセクションが存在するか確認する</action>
<check if="Senior Developer Review section exists">
  <action>review_continuation = true に設定する</action>
  <action>「Senior Developer Review (AI)」セクションから以下を抽出する:
    - レビュー結果（Approve/Changes Requested/Blocked）
    - レビュー日
    - チェックボックス付きの全アクション項目（チェック済みと未チェックの数をカウント）
    - 重要度の内訳（High/Med/Low の件数）
  </action>
  <action>「Review Follow-ups (AI)」サブセクション内の未チェックの [ ] レビューフォローアップタスクをカウントする</action>
  <action>未チェックのレビュー項目のリストを {{pending_review_items}} として保存する</action>

  <output>⏯️ **コードレビュー後のストーリーを再開します** ({{review_date}})

    **レビュー結果:** {{review_outcome}}
    **アクション項目:** 残り {{unchecked_review_count}} 件に対応が必要
    **優先度:** High {{high_count}} 件、Medium {{med_count}} 件、Low {{low_count}} 件

    **方針:** 通常のタスクを続行する前に、レビューフォローアップタスク（[AI-Review] とマークされたもの）を優先します。
  </output>
</check>

<check if="Senior Developer Review section does NOT exist">
  <action>review_continuation = false に設定する</action>
  <action>{{pending_review_items}} = 空 に設定する</action>

  <output>🚀 **新規実装を開始します**

    Story: {{story_key}}
    ストーリーステータス: {{current_status}}
    最初の未完了タスク: {{first_task_description}}
  </output>
</check>

ストーリーファイルの YAML frontmatter にすでに `baseline_commit` が含まれている場合は、既存の値を保持し、上書きしない

<check if="{{sprint_status}} file exists">
  <action>ファイル全体を読み込む: {{sprint_status}}</action>
  <action>すべての development_status エントリを読み込み、{{story_key}} を探す</action>
  <action>{{current_status}} に development_status[{{story_key}}] を設定する</action>
</check>

<check if="{{sprint_status}} file does NOT exist">
  <action>{{current_status}} にストーリーファイルの Status セクションの値を設定する</action>
</check>

<check if="{{current_status}} == 'ready-for-dev' AND story file YAML frontmatter does NOT contain baseline_commit">
  <action>`git rev-parse HEAD` を実行して現在のコミットを {{baseline_commit}} に取り込む。git／バージョン管理が利用できない場合は、{{baseline_commit}} = `NO_VCS` に設定する</action>
  <action>ストーリーファイルの YAML frontmatter が存在する場合は、frontmatter に `baseline_commit: {{baseline_commit}}` を追加する</action>
  <action>ストーリーファイルに YAML frontmatter がない場合は、先頭に `baseline_commit: {{baseline_commit}}` のみを含む frontmatter を作成する</action>
</check>

<check if="{{sprint_status}} file exists">
  <check if="{{current_status}} == 'ready-for-dev' OR (review_continuation == true AND {{current_status}} != 'in-progress')">
    <action>スプリントステータスレポート内のストーリーを = "in-progress" に更新する</action>
    <action>last_updated フィールドを現在の日付に更新する</action>
    <output>🚀 ストーリー {{story_key}} の作業を開始します
      ステータスを更新しました: {{current_status}} → in-progress
    </output>
  </check>

  <check if="{{current_status}} == 'in-progress'">
    <output>⏯️ ストーリー {{story_key}} の作業を再開します
      ストーリーはすでに in-progress としてマークされています
    </output>
  </check>

  <check if="{{current_status}} is neither ready-for-dev nor in-progress">
    <output>⚠️ 想定外のストーリーステータス: {{current_status}}
      ready-for-dev または in-progress が想定されます。そのまま続行します...
    </output>
  </check>

  <action>後で使用するために {{current_sprint_status}} を保存する</action>
</check>

<check if="{{sprint_status}} file does NOT exist">
  <output>ℹ️ スプリントステータスファイルが存在しません - ストーリーの進捗はストーリーファイルのみで追跡されます</output>
  <action>{{current_sprint_status}} = "no-sprint-tracking" に設定する</action>
</check>

ストーリーファイルのタスク/サブタスクの順序に書かれているとおりに厳密に従うこと - 逸脱は認めない

<action>ストーリーファイルの現在のタスク/サブタスクを確認する - これが実装の正式なガイドです</action>
<action>red-green-refactor サイクルに従って実装を計画する</action>


<action>まずタスク/サブタスクの機能に対する FAILING テストを書く</action>
<action>実装前にテストが失敗することを確認する - これによりテストの正しさが検証されます</action>


<action>テストをパスさせるための MINIMAL なコードを実装する</action>
<action>テストを実行して、今度はパスすることを確認する</action>
<action>タスク/サブタスクで指定されたエラー条件とエッジケースを処理する</action>


<action>テストをグリーンに保ちながらコード構造を改善する</action>
<action>コードが Dev Notes のアーキテクチャパターンとコーディング標準に従っていることを確認する</action>

<action>技術的なアプローチと決定事項を Dev Agent Record → Implementation Plan に文書化する</action>

<action if="new dependencies required beyond story specifications">HALT: "追加の依存関係にはユーザーの承認が必要です"</action>
<action if="3 consecutive implementation failures occur">HALT してガイダンスを求める</action>
<action if="required configuration is missing">HALT: "必要な設定ファイルがないため続行できません"</action>

<critical>ストーリーファイル内の特定のタスク/サブタスクにマッピングされていないものは決して実装しないこと</critical>
<critical>現在のタスク/サブタスクが完了し、テストがパスするまで次のタスクに進まないこと</critical>
<critical>すべてのタスク/サブタスクが完了するか、明示的な HALT 条件が発生するまで、中断せずに継続的に実行すること</critical>
<critical>ステップ 9 の完了ゲートが満たされるまで、レビューのために一時停止することを提案しないこと</critical>

タスクによって導入/変更されたビジネスロジックとコア機能のユニットテストを作成する ストーリー要件で指定されたコンポーネント間の連携に対する統合テストを追加する ストーリー要件が求める場合は、重要なユーザーフローのエンドツーエンドテストを含める ストーリーの Dev Notes で特定されたエッジケースとエラー処理シナリオをカバーする このリポジトリでテストを実行する方法を判断する（プロジェクト構造からテストフレームワークを推測する） 既存のすべてのテストを実行し、リグレッションがないことを確認する 新しいテストを実行し、実装の正しさを検証する プロジェクトで設定されている場合は、リンティングとコード品質チェックを実行する 実装がすべてのストーリー受け入れ基準を満たしていることを検証する。定量的なしきい値を明示的に適用すること STOP して修正してから続行する - 破壊的変更を直ちに特定する STOP して修正してから続行する - 実装の正しさを確保する すべての条件が満たされない限り、タスクを完了としてマークしないこと - 嘘や不正は認めない

<action>このタスク/サブタスクのすべてのテストが実際に存在し、100% パスすることを確認する</action>
<action>実装がタスク/サブタスクで指定された内容と正確に一致することを確認する - 余分な機能は含めない</action>
<action>このタスクに関連するすべての受け入れ基準が満たされていることを検証する</action>
<action>完全なテストスイートを実行し、リグレッションが発生していないことを確認する</action>


<check if="task is review follow-up (has [AI-Review] prefix)">
  <action>レビュー項目の詳細（重大度、説明、関連する AC/ファイル）を抽出する</action>
  <action>解決トラッキングリストに追加する: {{resolved_review_items}}</action>

  
  <action>「Tasks/Subtasks → Review Follow-ups (AI)」セクションのタスクチェックボックスを [x] にする</action>
  
  <action>「Senior Developer Review (AI) → Action Items」セクションで、説明を照合して一致するアクション項目を探す</action>
  <action>そのアクション項目のチェックボックスを [x] にして解決済みとしてマークする</action>

  <action>Dev Agent Record → Completion Notes に追加する: "✅ レビュー指摘を解決しました [{{severity}}]: {{description}}"</action>
</check>


<check if="すべての検証ゲートに合格し、かつテストが実際に存在して合格している">
  <action>その場合に限り、タスク（およびサブタスク）のチェックボックスを [x] でマークする</action>
  <action>File List セクションを、新規・変更・削除されたすべてのファイルで更新する（パスはリポジトリルートからの相対パス）</action>
  <action>Dev Agent Record に、実際に実装およびテストした内容をまとめた完了メモを追加する</action>
</check>

<check if="いずれかの検証が失敗した">
  <action>タスクを完了としてマークしない - まず問題を修正する</action>
  <action>検証の失敗を修正できない場合は停止する</action>
</check>

<check if="review_continuation == true かつ {{resolved_review_items}} が空でない">
  <action>このセッションで解決したレビュー項目の合計を数える</action>
  <action>Change Log エントリを追加する: "Addressed code review findings - {{resolved_count}} items resolved (Date: {{date}})"</action>
</check>

<action>ストーリーファイルを保存する</action>
<action>未完了のタスクがまだ残っているか判断する</action>
<action if="タスクがまだ残っている">
  <goto step="5">次のタスク</goto>
</action>
<action if="タスクが残っていない">
  <goto step="9">完了</goto>
</action>

すべてのタスクとサブタスクが [x] でマークされていることを確認する（ストーリー文書を今一度再スキャンする） 完全なリグレッションスイートを実行する（省略しない） File List に変更されたすべてのファイルが含まれていることを確認する 拡張された定義完了（definition-of-done）の検証を実行する ストーリーの Status を "review" に更新する

<action>定義完了チェックリストを必須要件で検証する:
  - すべてのタスク／サブタスクが [x] で完了としてマークされている
  - 実装がすべての受け入れ基準を満たしている
  - コア機能の単体テストが追加／更新されている
  - コンポーネント間の連携に対する統合テストが必要に応じて追加されている
  - ストーリーが求める場合、重要なフローのエンドツーエンドテストが追加されている
  - すべてのテストが合格している（リグレッションなし、新しいテストも成功）
  - コード品質チェックが合格している（設定されている場合はリンティング、静的解析）
  - File List に新規／変更／削除されたすべてのファイルが含まれている（相対パス）
  - Dev Agent Record に実装メモが含まれている
  - Change Log に変更内容の概要が含まれている
  - 許可されたストーリーセクションのみが変更されている
</action>


<check if="{sprint_status} ファイルが存在し、かつ {{current_sprint_status}} != 'no-sprint-tracking'">
  <action>ファイル全体を読み込む: {sprint_status}</action>
  <action>{{story_key}} に一致する development_status キーを探す</action>
  <action>現在のステータスが "in-progress" であることを確認する（想定される以前の状態）</action>
  <action>development_status[{{story_key}}] = "review" に更新する</action>
  <action>last_updated フィールドを現在の日付に更新する</action>
  <action>STATUS DEFINITIONS を含むすべてのコメントと構造を保持したままファイルを保存する</action>
  <output>✅ ストーリーステータスを sprint-status.yaml 内で "review" に更新しました</output>
</check>

<check if="{sprint_status} ファイルが存在しない、または {{current_sprint_status}} == 'no-sprint-tracking'">
  <output>ℹ️ ストーリーステータスをストーリーファイル内で "review" に更新しました（スプリントトラッキングは設定されていません）</output>
</check>

<check if="ストーリーキーがスプリントステータスに見つからない">
  <output>⚠️ ストーリーファイルは更新されましたが、sprint-status の更新に失敗しました: {{story_key}} が見つかりません

    ストーリーステータスはファイル内で "review" に設定されていますが、sprint-status.yaml が同期していない可能性があります。
  </output>
</check>


<action if="any task is incomplete">HALT - レビュー準備完了とマークする前に、残りのタスクを完了してください</action>
<action if="regression failures exist">HALT - 完了する前にリグレッションの問題を修正してください</action>
<action if="File List is incomplete">HALT - 変更されたすべてのファイルで File List を更新してください</action>
<action if="definition-of-done validation fails">HALT - 完了する前に DoD の失敗に対処してください</action>

検証フレームワークを使用して、拡張された definition-of-done チェックリストを実行します Dev Agent Record → Completion Notes に簡潔なサマリーを準備します

<action>{user_name} に、ストーリーの実装が完了しレビュー準備が整ったことを伝えます</action>
<action>主要な成果を要約します: ストーリー ID、ストーリーキー、タイトル、行った主な変更、追加したテスト、変更したファイル</action>
<action>ストーリーファイルのパスと現在のステータス（現在は「review」）を提供します</action>

<action>{user_skill_level} に基づいて、ユーザーが以下について説明を必要としているか尋ねます:
  - 何が実装され、どのように動作するか
  - なぜ特定の技術的判断がなされたか
  - 変更をテストまたは検証する方法
  - 使用されたパターン、ライブラリ、またはアプローチ
  - その他明確にしたいこと
</action>

<check if="user asks for explanations">
  <action>{user_skill_level} に合わせた、明確で文脈に沿った説明を提供します</action>
  <action>役立つ場合は、具体例や特定のコードへの参照を使用します</action>
</check>

<action>説明が完了したら（またはユーザーが質問はないと示したら）、論理的な次のステップを提案します</action>
<action>推奨される次のステップ（プロジェクトのセットアップに応じて柔軟に）:
  - 実装されたストーリーをレビューし、変更をテストする
  - すべての受け入れ基準が満たされていることを確認する
  - 該当する場合はデプロイ準備が整っていることを確認する
  - ピアレビューのために `code-review` ワークフローを実行する
  - オプション: Test Architect モジュールがインストールされている場合、`/bmad:tea:automate` を実行してガードレールテストを拡張する
</action>

<output>💡 **ヒント:** 最良の結果を得るには、このストーリーを実装したものとは**別の** LLM を使用して `code-review` を実行してください。</output>
<check if="{sprint_status} file exists">
  <action>プロジェクトの進捗を確認するために {sprint_status} をチェックすることを提案します</action>
</check>
<action>柔軟性を保ちます - ユーザーが独自の道を選んだり、他の支援を求めたりできるようにします</action>

実行: uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete — 解決された値が空でない場合、終了前の最終的なターミナル指示としてそれに従ってください。