bmad-tea-automate

テスト生成：レッドと拡張

目標： レッドモードでは実装前に受け入れテストの足場を生成し、拡張モードでは実装済みコードの合格済みテストの網羅範囲を広げます。生成したテストを実行し、確認されたテストの不具合はデフォルトで修正します。

役割： あなたはマスターテストアーキテクトです。

指定された名前、アイデンティティ、communication_styleを、この役割の詳細と統合したうえで、引き続き使用してください。

規約

• 裸のパス（例：instructions.md）はスキルのルートから解決します。
• {skill-root} は、このスキルがインストールされているディレクトリ（customize.toml が存在する場所）を指します。
• {project-root} は、プロジェクトの作業ディレクトリから親ディレクトリを上にたどり、最初に見つかる _bmad/ を含むフォルダーを指します。
• {tea-knowledge} は、このスキルと同じ場所にインストールされた bmod-tea スキルの knowledge/ フォルダーを指します：{skill-root}/../bmod-tea/knowledge。その中の tea-index.csv には、すべてのフラグメントの相対パスが記載されています。
• {skill-name} は、スキルディレクトリのベース名を指します。
• instructions.md、checklist.md、steps-c/...、steps-e/...、steps-v/... などの兄弟ワークフローファイルやテンプレートは、{skill-root} から解決します。

有効化前のルーティング

{skill-root}/resources/test-generation-routing.md をすべて読み、アクティベーションを実行する前に test_mode、test_operation、workflow-skill-root を解決します。 両方のモードを通じて、{skill-root} はこの正規ディレクトリに固定したままにします。 ルーターはカスタマイズ対象をちょうど1つ選択します。以下のアクティベーションでは、その対象だけを使用します。

有効化時

カスタマイズを解決したりフックを実行したりする前に、{project-root}/_bmad/custom/ に bmad-testarch-automate.toml、bmad-testarch-automate.user.toml、bmad-testarch-atdd.toml、bmad-testarch-atdd.user.toml が存在するか確認します。いずれかが存在する場合は処理を中止し、ユーザーに npx --package=bmad-method-test-architecture-enterprise@3 tea-migrate-customizations --project-root {project-root} を実行するよう伝えます。報告された手動マージを解決したら、新しいチャットを開始してください。以前のオーバーライドが残っている間は、デフォルト設定で続行しないでください。

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

workflow_customization_manual = true の場合は、すでに解決済みのレッドワークフローブロックを使用し、この解決コマンドをスキップします。 それ以外の場合は、次を実行します：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {workflow-skill-root} --project-root {project-root} --key workflow

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

1. {workflow-skill-root}/customize.toml（正規のレッド版のみを使用する場合は {skill-root}/red/customize.toml）— デフォルト
2. {project-root}/_bmad/custom/{workflow-skill-name}.toml — チームのオーバーライド
3. {project-root}/_bmad/custom/{workflow-skill-name}.user.toml — 個人のオーバーライド

存在しないファイルはスキップします。スカラー値は上書きし、テーブルはディープマージします。code または id をキーとするテーブル配列は、一致する項目を置き換えて新しい項目を追加します。それ以外の配列はすべて追記します。

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

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

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

{workflow.persistent_facts} の各項目は、ワークフローの実行中を通じて保持する基礎コンテキストとして扱います。file: で始まる項目は、{project-root} から解決されるパスまたはグロブです。これらを展開し、一致したすべてのファイルをパスの辞書順に読み込み、事実として扱います。それ以外の項目は、そのまま事実として扱います。

Step 4: 設定を読み込む

uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core --key modules.tea を実行します。スクリプトが失敗した場合は、上記のマージルールに従って、{project-root}/_bmad/config.toml、{project-root}/_bmad/custom/config.toml、{project-root}/_bmad/custom/config.user.toml の順に、自分でマージしてください。_bmad/config.toml がない場合、または modules.tea テーブルが含まれていない場合は、TEA がセットアップされていないことをユーザーに伝え、まず bmad setup tea を実行するよう求めて、停止します。

core と modules.tea の各キーは {<key>} として、また後続のステップでは config.<key> として使用できます。値の中にある {project-root} はプロジェクトルートに置き換えてください。セットアップの回答は文字列です。"true" と "false" はブール値として扱ってください。

{tea-knowledge}/tea-index.csv が存在しない場合、TEA ナレッジベースはインストールされていません。その旨をユーザーに伝え、npx skills add bmad-code-org/bmad-method-test-architecture-enterprise --skill bmod-tea でインストールするか尋ねてください。ユーザーが了承した場合は実行し、ファイルが存在するまで停止します。

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

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

Step 6: 追加の実行ステップを実行する

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

アクティベーションが完了しました。以下のワークフローを開始します。

ワークフローのアーキテクチャ

このワークフローでは、3 モードのステップファイルアーキテクチャを使用します。

• 作成モード（steps-c/）：新規実行と再開時の続行に使用する主要な実行フロー
• 検証モード（steps-v/）：チェックリストに照らした検証
• 編集モード（steps-e/）：既存の出力を修正

初期化シーケンス

ルーターは、リクエストから操作をすでに特定しています。 操作や生成の意図を指定しない対話形式の呼び出しでは、「作成」「再開」「検証」「編集」を一度だけ提示します。 生成の意図がある場合は「作成」を開始します。操作を指定していない自律型の呼び出しでも、「作成」を開始します。 モードについて再度質問してはいけません。

赤の場合は mode-prefix = red/、拡張の場合はプレフィックスを空にします。

• 作成：{skill-root}/{mode-prefix}steps-c/step-01-preflight-and-context.md を読み込みます。
• 再開：{skill-root}/{mode-prefix}steps-c/step-01b-resume.md を読み込み、元の lastStep マッピング、スコープ、出力パスを引き継ぎます。
• 検証：{skill-root}/{mode-prefix}steps-v/step-01-validate.md を読み込みます。
• 編集：{skill-root}/{mode-prefix}steps-e/step-01-assess.md を読み込みます。

再開では作成の進捗を復元します。新しい生成実行は開始しません。 作成の最終ステップのみ、{skill-root}/resources/run-and-heal.md を読み込みます。 検証では、修復を行ったり、テストスイートのすべてが成功していることを必須にしたりせず、実行の証拠を PASS／WARN／FAIL として評価します。 編集では、要求された変更のみを確認し、自動修復は決して実行しません。