mcpField
B
bmad-testarch-trace

bmad-testarch-trace

github.com/bmad-code-orgテスト・品質112200 回インストール1 日前に更新
リポジトリ

bmad-testarch-trace について

bmad-testarch-traceは、要件やユーザージャーニーとテストを対応付け、カバレッジを分析して品質ゲートを判定するBMADテストアーキテクチャスキルです。作成、再開、検証、編集のワークフローに対応し、スコープ別に出力を保存します。

主な機能

  1. 01要件やジャーニーをテストに対応付け
  2. 02テストカバレッジを分析
  3. 03PASS、CONCERNS、FAIL、WAIVEDを判定
  4. 04作成・再開・検証・編集のワークフロー
  5. 05スコープ別にトレース成果物を保存

活用シーン

  1. 01Story、Epic、Releaseのテストカバレッジ確認
  2. 02トレーサビリティマトリクスとゲート判定の生成
  3. 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.toml
checklist.md
customize.toml
instructions.md
trace-template.md
workflow.yaml
resources/
live-verification-results.example.json
traceability-matrix.example.md
steps-c/
step-01-load-context.md
step-01b-resume.md
step-02-discover-tests.md
step-03-map-criteria.md
step-04-analyze-gaps.md
step-05-gate-decision.md
steps-e/
step-01-assess.md
step-02-apply-edit.md
steps-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 ブロックを自分で解決します。

  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} を基準に解決されるパスまたはグロブです。展開して、一致するすべてのファイルをパスの辞書順で読み込み、事実として扱います。それ以外の項目は、記載されたとおりに事実として扱います。

ステップ 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 です。あるスコープの実行で、別のスコープの出力を読み取ったり書き込んだりすることはありません。

コメント