bmad-tea-evaluate

評価

概要

目標： 対象について説明された内容をもとに、採点付きの開発と非公開評価を行い、明示されたギャップと修正内容を提示して、適用を強制する CI 計画を完成させます。

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

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

規約

• 裸のパス（例：references/inspection.md）はスキルのルートから解決します。
• {skill-root} は、このスキルがインストールされているディレクトリ（customize.toml がある場所）を指します。
• {project-root} は、作業ディレクトリの最も近い祖先のうち、_bmad ディレクトリを含むものを指します。
• {skill-name} は、スキルディレクトリのベース名を指します。
• references/... や assets/... などの兄弟ファイルは、{skill-root} から解決します。

実行権限

アクティベーション、カスタマイズの解決、フックの実行より前に、意図を確認します。通常の評価では、現在のワークフローを変更しません。ネイティブのクリーン／変更済み試行、実行の比較、ベースラインの受け入れは、従来の権限と意味を維持します。

明示的なネイティブ比較／受け入れリクエストでは、保存済み実行の比較中に一貫性への言及があっても、そのコマンドの権限が維持されます。保存済み結果の一貫性分析は、ユーザーが既存結果のばらつき分析を求めた場合に限り、実験ルートとして扱います。ルートを選択する前に、会話の文脈から「これらの結果」などの表現の指すものを確認します。

• 保存済み結果の一貫性分析、または明示的に求められたオフライン実験分析：references/configuration-experiments.md を読み込み、そのオフラインルートを直接実行します。prepend、append、completion フックは抑止します。構成解決スクリプト、モデル呼び出し、ジャッジ呼び出し、新たな試行は実行しません。保存済みの証拠を報告したら終了します。
• 新規の再現性確認、または単一要因の構成実験：references/configuration-experiments.md を直接読み込みます。このルートの全工程で、prepend、append、completion フックを抑止します。フックによって実行権限や支出権限が与えられることはありません。
• 保存済み記録と新規実行のどちらを指すか明示されていない「再現性はありますか？」という質問：何かを実行する前に、保存済み記録と新規実行のどちらかを確認します。
• 通常の評価、通常のオフライン記録評価、またはネイティブ比較／受け入れ（保存済み実行の比較を含む）：以下の「アクティベーション時」の手順に進みます。実験ガイドを読み込んだり、実験を分析したり、通常の結果の後に試行を追加したりしません。

アクティベーション時

カスタマイズの解決やフックの実行より前に、{project-root}/_bmad/custom/ に bmad-testarch-evaluate.toml と bmad-testarch-evaluate.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：prepend ステップを実行する

続行する前に、{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_evaluations_folder} は、{project-root} を基準とした {workflow.evaluations_folder} です。

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

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

ステップ 6：追加の実行ステップ

{workflow.activation_steps_append} の各エントリーを順に実行します。

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

ワークフロー

Evaluate は、個別のステップファイルではなくインラインで実行する、12 ステージからなる継続的なループです。各ステージの作業手順は、それぞれのステージに到達した時点で読み込む references/ ガイドに記載されています。採用者が別の場所を指定しない限り、{tea_evaluations_folder} を作業場所とします。再開する際は、ステージを選ぶ前に既存の検査記録、evaluation.json、requirements.md、authoring-log.md、<evaluation-folder>/ci/evaluation-ci-plan.json、および {test_artifacts}/evaluate/<evaluationId>/gap-report.md を読み込みます。ステージ 3 の前に、声明に対する採用者の確認を必須とし、コミット済みファイルに対する eval-quality の digestBytes と requirements.digest を比較します。それ以外の場合は、受付に戻ります。未完了の最初のステージから、または前提条件が満たされている場合は採用者が指定したステージから続行します。assets/README.md には、assets/ 内の各テンプレートの記入方法が記載されています。

作成作業を委任する前に references/authoring-routing.md を読み込みます。ホストがサブエージェントに対応している場合は、ループ全体を通して、その限定された作業タスクと作成台帳を使用します。

ステージの作業手順を独自に推測して実行してはいけません。また、eval-quality 自身の CLI（AD-6）以外で、判定、スコア、合否を計算してはいけません。このスキルが独自に計算した判定は、eval-quality によって封印されたものではありません。

ステージ 1：検査

対象を調査し、その種類を特定します。references/inspection.md を読み込みます。

ステージ 2：受付

採用者が確認した動作要件と制約を記録します。references/intake.md を読み込みます。

ステージ 3：コーパス

プローブコーパスを設計します。references/corpus.md を読み込みます。

ステージ 4：契約

Behavioral Evaluation Contract を作成します。references/contract.md を読み込みます。確認済みの requirements.md のバイト列に対する eval-quality の digestBytes を使って sourceSpecDigest を設定し、evaluation.json の requirements.digest と一致させます。

ステージ 5：オラクル

オラクルとルーブリックを設計します。references/oracles.md を読み込みます。

ステージ 6：アダプター

実行先レジストリとアダプターをひな形から作成します。references/adapters.md を読み込みます。

コントラクト、オラクル、レジストリを記入したら、assets/evaluator-conditions.template.json を policy/evaluator-conditions.json にコピーし、対象の modelSnapshot と systemPromptDigest を記入します。tea-skill-runner レジストリには、実際のモデルスナップショットが必要です。ルーブリックを用いる決定論的評価器の場合は、evaluation.json.judge を宣言し、judge.modelSnapshot を記入します。それ以外の場合は、使用しないテンプレートの judge ブロックを削除します。プローブが controlled-mutation、historical、または gameability の経路を取る場合は、policy/scoring-policy.json がインストール済みテンプレートからコピーされ、必要事項が記入されていることを確認します。導入者に policyId としきい値を確認してから、evaluation.json.trials を minimumTrialCount 以上に設定します。

最初の tea-evaluate check を実行する前に、references/mutation.md を読み込み、ステージ 3 の controlled-mutation プローブで指定されたすべての mutations/<mutationId>.mutation.json を作成します。導入者が所有する対象を使用し、置換は正確に 1 つだけにして、プローブの観測可能な欠陥シグネチャを使います。これらのファイルを書き込んだら、corpus-index.json を更新します。導入者のインストールでは、npm exec --prefix {tea_evaluations_folder} -- tea-evaluate digest --evaluation <evaluation-folder> を実行します。TeA 独自のパッケージでは、リポジトリのルートから node cli/evaluate.js digest --evaluation <evaluation-folder> を実行します。ステージ 6 の事前チェックでは指定されたプローブの適格性を確認し、ステージ 8 ではその発現とロールバックの証拠を調べて、ミューテーションのセットを拡充します。

導入者のインストールでは、npm exec --prefix {tea_evaluations_folder} -- tea-evaluate check --evaluation <evaluation-folder> を実行し、続けて npm exec --prefix {tea_evaluations_folder} -- eval-quality compile --in <evaluation-folder>/contract.json --out <evaluation-folder>/compiled-contract.json、さらに npm exec --prefix {tea_evaluations_folder} -- eval-quality seal --in <evaluation-folder>/contract.json --out <evaluation-folder>/sealed-brief.json を実行します。TeA 独自のパッケージでは、リポジトリのルートから node cli/evaluate.js check --evaluation <evaluation-folder> を実行し、続けて ./node_modules/.bin/eval-quality compile --in <evaluation-folder>/contract.json --out <evaluation-folder>/compiled-contract.json、さらに ./node_modules/.bin/eval-quality seal --in <evaluation-folder>/contract.json --out <evaluation-folder>/sealed-brief.json を実行します。ローカルの CLI とバイナリは、そのルートにある 1 つの eval-quality インストールを使用します。終了コードが 0 以外になった時点で停止します。成果物を変更してそのステージを再実行する前に、該当するコマンド、終了コード、stderr を報告してください。

seal が成功したら、最初の事前チェックで runs/ が作成される前に、assets/evaluation-folder.gitignore を <evaluation-folder>/.gitignore にコピーします。ライブ事前チェックの前に、references/run.md の Git 分離手順に従います。Git ワークツリーは作業ファイルが別々でも、refs は共有されます。導入者のインストールでは、npm exec --prefix {tea_evaluations_folder} -- tea-evaluate preflight --evaluation <evaluation-folder> --partition development を実行します。TeA 独自のパッケージでは、リポジトリのルートから node cli/evaluate.js preflight --evaluation <evaluation-folder> --partition development を実行します。これにより、選択したレジストリが起動でき、クリーンなコントロールを満たせることを確認します。evaluation.json で partitionPlan が宣言されている場合に限り、このフラグが必須です。--partition を付けずに実行すると、終了コード 64 で終了します。保留データの事前チェック（--partition held-out）は、開発レビューの後にのみ実行します。失敗した場合は停止し、コマンド、終了コード、stderr を報告します。事前チェックが成功してから、アダプターの接続設定を完了します。

ステージ 7：評価器

評価レイヤーを選択または構築します。references/evaluator.md を読み込みます。

ステージ 8：ミューテーション

制御されたミューテーションを適用し、ロールバックします。references/mutation.md を読み込みます。

ステージ 9：ハーネス

ランナーとスコアリングポリシーをひな形から作成します。references/harness.md を読み込みます。

ステージ 10：実行

クリーンアームとミューテーションアームを実行し、採点します。references/run.md を読み込みます。

ステージ 11：ギャップ

結果が弱い場合は解釈し、ギャップを埋めます。references/gaps.md を読み込みます。

ステージ 12：CI

導入先のリポジトリを調査し、各チェックをティアに分類して、<evaluation-folder>/ci/evaluation-ci-plan.json を作成し、CI セットアップの範囲を指定して bmad-tea-framework に渡します。references/ci.md を読み込みます。

完了時

次を実行します：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete

リゾルバーが成功し、空でない workflow.on_complete を返した場合は、終了する前に、その値を最後のターミナル指示として実行します。

リゾルバーが失敗する、出力がない、または空の値に解決された場合は、フックをスキップして通常どおり終了します。