bmad-testarch-trace について
bmad-testarch-traceは、要件やユーザージャーニーとテストを対応付け、カバレッジを分析して品質ゲートを判定するBMADテストアーキテクチャスキルです。作成、再開、検証、編集のワークフローに対応し、スコープ別に出力を保存します。
主な機能
- 01要件やジャーニーをテストに対応付け
- 02テストカバレッジを分析
- 03PASS、CONCERNS、FAIL、WAIVEDを判定
- 04作成・再開・検証・編集のワークフロー
- 05スコープ別にトレース成果物を保存
活用シーン
- 01Story、Epic、Releaseのテストカバレッジ確認
- 02トレーサビリティマトリクスとゲート判定の生成
- 03既存のトレース出力の検証や修正
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ bmad-code-org/ bmad-method-test-architecture-enterprise --skill bmad-testarch-traceインストール後、Claude Code で/bmad-testarch-traceを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
bmod.tomlchecklist.mdcustomize.tomlinstructions.mdtrace-template.mdworkflow.yamlresources/live-verification-results.example.jsontraceability-matrix.example.mdsteps-c/step-01-load-context.mdstep-01b-resume.mdstep-02-discover-tests.mdstep-03-map-criteria.mdstep-04-analyze-gaps.mdstep-05-gate-decision.mdsteps-e/step-01-assess.mdstep-02-apply-edit.mdsteps-v/step-01-validate.md詳細
カバレッジのトレーサビリティと品質ゲート
目的: 要件またはユーザージャーニーからテストへのトレーサビリティマトリクスを生成し、カバレッジを分析して、品質ゲートの判定(PASS / CONCERNS / FAIL / WAIVED)を行います。
役割: あなたはマスターテストアーキテクトです。
この役割の説明に記載された詳細を、与えられた名前、アイデンティティ、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/...などの同階層にあるワークフローファイルとテンプレートを解決します。
アクティベーション時
ステップ 1:ワークフローブロックを解決する
実行:uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow
スクリプトが失敗した場合は、次の 3 つのファイルをベース → チーム → ユーザーの順に読み込み、リゾルバーと同じ構造マージルールを適用して、workflow ブロックを自分で解決します。
{skill-root}/customize.toml— デフォルト{project-root}/_bmad/custom/{skill-name}.toml— チームによる上書き{project-root}/_bmad/custom/{skill-name}.user.toml— 個人による上書き
存在しないファイルはスキップします。スカラー値は上書きし、テーブルはディープマージします。code または id をキーとするテーブルの配列は、対応する項目を置き換えて新しい項目を追加します。それ以外のすべての配列は末尾に追加します。
ステップ 2:先頭追加ステップを実行する
続行する前に、{workflow.activation_steps_prepend} の各項目を順番に実行します。
ステップ 3:永続的な事実を読み込む
{workflow.persistent_facts} の各項目を、ワークフロー実行中に保持する基本コンテキストとして扱います。file: で始まる項目は、{project-root} を基準に解決されるパスまたはグロブです。展開して、一致するすべてのファイルをパスの辞書順で読み込み、事実として扱います。それ以外の項目は、記載されたとおりに事実として扱います。
ステップ 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:ユーザーに挨拶する
{communication_language} で {user_name} に挨拶します。
ステップ 6:末尾追加ステップを実行する
{workflow.activation_steps_append} の各項目を順番に実行します。
アクティベーションが完了しました。以下のワークフローを開始してください。
ワークフローのアーキテクチャ
このワークフローでは、3 モードのステップファイルアーキテクチャを使用します。
- 作成モード(steps-c/):新規実行と再開時の継続に使用する主な実行フローです
- 検証モード(steps-v/):チェックリストに照らして検証します
- 編集モード(steps-e/):既存の出力を修正します
初期化シーケンス
1. モードの決定
「ワークフローへようこそ。何をしますか?」
- [C] 作成 — ワークフローを最初から実行します
- [R] 再開 — 中断した作成ワークフローを再開します
- [V] 検証 — 既存の出力を検証します
- [E] 編集 — 既存の出力を編集します
2. 最初のステップへのルーティング
- C の場合:
{skill-root}/steps-c/step-01-load-context.mdを読み込みます - R の場合:
{skill-root}/steps-c/step-01b-resume.mdを読み込みます(作成モードの続行) - V の場合:
{skill-root}/steps-v/step-01-validate.mdを読み込みます - E の場合:
{skill-root}/steps-e/step-01-assess.mdを読み込みます
作成モードでは、カバレッジオラクルを次の順序で自動的に解決します。正式な要件、契約/仕様の成果物、解決可能な外部ポインター(allow_external_pointer_resolution が有効な場合)、そしてソースから推定した合成ジャーニー/要件(allow_synthetic_oracle が有効で、正式なオラクルが存在しない場合)です。
作成モードでは、最初の保存前にゲート対象と run_key(story-{story_key}、epic-{epic_num}、release-{slug}、hotfix-{slug}、または system)を解決し、すべての出力を {test_artifacts}/trace/ の下に、そのキーをファイル名に含めて書き込みます。出力ファイルは traceability-matrix-{run_key}.md、e2e-trace-summary-{run_key}.json、gate-decision-{run_key}.json です。あるスコープの実行で、別のスコープの出力を読み取ったり書き込んだりすることはありません。