mcpField
B
bmad-tea-test-design

bmad-tea-test-design

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

bmad-tea-test-design について

bmad-tea-test-designは、リスクに基づくエピック単位のテスト計画を作成するBMadテストアーキテクチャスキルです。作成、再開、検証、編集に対応し、実行ごとに進捗チェックポイントを分けて管理します。

主な機能

  1. 01リスクとテスト容易性の評価
  2. 02エピック単位のテスト計画
  3. 03作成・再開・検証・編集モード
  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-test-design

インストール後、Claude Code で/bmad-tea-test-designを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

bmod.toml
checklist.md
customize.toml
instructions.md
test-design-architecture-template.md
test-design-handoff-template.md
test-design-qa-template.md
test-design-template.md
workflow.yaml
resources/
test-design-epic-3.example.md
steps-c/
step-01-detect-mode.md
step-01b-resume.md
step-02-load-context.md
step-03-risk-and-testability.md
step-04-coverage-plan.md
step-05-generate-output.md
steps-e/
step-01-assess.md
step-02-apply-edit.md
steps-v/
step-01-validate.md

詳細

テスト設計とリスク評価

目標: リスクとテスト容易性の評価に基づいた、エピックレベルのテスト計画を作成します。

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

この役割の説明にある詳細を統合したうえで、与えられた名前、アイデンティティ、コミュニケーションスタイルを引き継いでください。

規約

  • 裸のパス(例: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-test-design.toml と bmad-testarch-test-design.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:ユーザーに挨拶する

{user_name} に、{communication_language} で挨拶してください。

ステップ 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-detect-mode.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 を読み込みます

すべての出力は {test_artifacts}/test-design/ の下に保存されます。システムレベルの test-design-architecture.md と test-design-qa.md、エピック計画の test-design-epic-{epic_num}.md、{project_name}-handoff.md ドキュメント、そして exploration/ 内の調査スクリーンショットが含まれます。

各実行では、{test_artifacts}/test-design/test-design-progress-{run_key}.md に独自の進捗チェックポイントを書き込みます。run_key はシステムレベルの実行では system、エピックレベルの実行では epic-{epic_num} です。ステップ 1 でチェックポイントを特定するため、あるエピックの実行を中断して別のエピックを開始しても、最初のエピックのチェックポイントが上書きされることはありません。

再開モードでは、再開対象の実行に一致するチェックポイントが選択されます。対象範囲が指定されておらず、複数のチェックポイントがある場合は確認を求めます。また、runKey が別の実行に属するチェックポイントの続行は拒否します。明示的な進捗メタデータ(workflowStatus、nextStep、totalSteps)を読み取り、必要に応じて従来の lastStep データにフォールバックします。

コメント