mcpField
B
bmad-tea-trace

bmad-tea-trace

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

bmad-tea-trace について

bmad-tea-traceは、要件やユーザージャーニーをテストに対応付け、カバレッジを分析して品質ゲートの判定を作成するBMadテストアーキテクチャスキルです。正式な要件、契約資料、外部参照、推定したジャーニーをカバレッジの根拠にできます。

主な機能

  1. 01要件からテストへのトレーサビリティ表
  2. 02カバレッジ分析
  3. 03PASS・CONCERNS・FAIL・WAIVEDの判定
  4. 04カバレッジ根拠の解決

活用シーン

  1. 01要件に対するテストカバレッジの追跡
  2. 02リリースやホットフィックスのカバレッジ評価
  3. 03対象範囲を限定した品質ゲート判定の作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise --skill bmad-tea-trace

インストール後、Claude Code で/bmad-tea-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} は、スキルディレクトリのベース名として解決します。
  • instructions.md、checklist.md、steps-c/...、steps-e/...、steps-v/...などの兄弟ワークフローファイルとテンプレートは、{skill-root}から解決します。

有効化時

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

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

コメント