bmad-testarch-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} は、スキルディレクトリのベース名を指します。
• {skill-root} を基準に、instructions.md、checklist.md、steps-c/...、steps-e/...、steps-v/... などの同階層にあるワークフローファイルやテンプレートを解決します。

有効化の前にルートを決定

{skill-root}/resources/test-generation-routing.md を最後まで読み、test_mode、test_operation、workflow-skill-root を解決してから有効化を実行します。 両方のモードを通じて、{skill-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} から解決するパスまたは glob です。これらを展開し、一致するすべてのファイルをパスの辞書順で読み込み、事実として扱います。それ以外の項目は、記載どおりの事実として扱います。

ステップ 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 でインストールすることを提案します。同意が得られたらそのコマンドを実行し、インストールされるまで停止します。

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

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

ステップ 6：追加ステップを実行する

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

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

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

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

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

初期化シーケンス

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

red の場合は mode-prefix = red/ を、expand の場合は空のプレフィックスを使用します。

• 作成：{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 で評価します。修復は行わず、テストスイートがすべて成功していることも求めません。 「編集」では依頼された変更のみを確認し、自動修復は実行しません。