bmad-testarch-evaluate

評価

概要

目標： 記述された目標から始める採用者を、スコア付きの開発と保留評価に導き、明確なギャップと修正策を示したうえで、それを徹底する CI 計画を完成させます。

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

この役割の説明にある詳細を取り入れつつ、与えられた名前、アイデンティティ、コミュニケーションスタイルを引き継いで作業します。

規約

• 裸のパス（例：references/inspection.md）はスキルのルートを基準に解決します。
• {skill-root} は、このスキルがインストールされているディレクトリ（customize.toml が置かれている場所）を指します。
• {project-root} は、作業ディレクトリから最も近い祖先のうち、_bmad ディレクトリを含むものを指します。
• {skill-name} は、スキルディレクトリのベース名を指します。
• references/... や assets/... などの兄弟ファイルは、{skill-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_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 があればその内容を読み込んでください。Stage 3 に進む前に、導入者が要件を確認したことを明記した確認を求め、確定済みファイルに対する eval-quality の digestBytes で requirements.digest を照合してください。そうでない場合は、インテークに戻ってください。最初に未完了の段階から、または前提条件を満たしている場合は導入者が指定した段階から続行してください。assets/README.md には、assets/ 内の各テンプレートの記入方法が記載されています。

作成作業を委任する前に、references/authoring-routing.md を読んでください。ホストがサブエージェントに対応している場合は、ループ全体を通じて、そこで定められた範囲内のワーカータスクと作成台帳を使用してください。

各段階の作業手順を独自に推測して進めてはいけません。また、eval-quality 自身の CLI 以外で、判定、スコア、合否を決定してはいけません（AD-6）。このスキルが独自に算出した判定は、eval-quality によって封印されたものではないためです。

Stage 1：検査

対象を検査し、その種類を特定してください。references/inspection.md を読み込んでください。

Stage 2：インテーク

導入者が確認した動作要件と制約を記録してください。references/intake.md を読み込んでください。

Stage 3：コーパス

プローブコーパスを設計してください。references/corpus.md を読み込んでください。

Stage 4：コントラクト

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

Stage 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-testarch-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 を返した場合は、終了する前に、その値を最後のターミナル命令として実行します。

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