create-skill-test

スキルテストの作成

スキル、エージェント、またはワークフローパッケージ用の評価仕様（eval.yaml）を作成し、Vally スキーマに準拠させ、 skill-validator check と check_eval_quality.py に合格し、判定を返せるだけの十分な能力を備えつつ、 スキル独自の表現に過剰適合しないようにします。

使用するタイミング

• スキル、エージェント、またはワークフローパッケージ用に新しい eval.yaml を作成するとき
• 既存の評価に刺激を追加するとき
• 合格ゲートに実際に到達できるよう評価の規模を調整するとき
• 評価と並ぶフィクスチャファイルを設定または修復するとき
• ルーブリック項目と採点者が過剰適合のリスクを生じさせていないか確認するとき

使用しないタイミング

• 失敗した評価や性能が低下した評価を診断するとき — improve-skill-quality を使用してください
• skill-validator や評価ワークフローを変更するとき
• SKILL.md ファイルを作成または編集するとき — create-skill を使用してください

入力

入力	必須	説明
スキル名またはエージェント名	はい	plugins/<plugin>/skills/ または plugins/<plugin>/agents/ 配下に存在する必要があります
プラグイン名	はい	例：dotnet-msbuild
スキルの内容	はい	読んでください。内容を知らずに過剰適合しないルーブリック項目を書くことはできません
シナリオ仮説	はい	選好ケースで期待する改善、またはガードによって保護される不変条件を記述します
識別する失敗モード	推奨	それぞれが固有の刺激になります

ワークフロー

ステップ 1：評価が対象に適切であることを証明する

YAML を書く前に、刺激によって何が証明されるのかを明確にします。選好刺激は、対象によって、対象がない同じモデルと比べて、回答、動作、抑制、または検証結果が改善されるべき場合に必要です。正しい動作がベースラインと同等でも、意味のある不変条件を保護するには、投票対象外のアクティベーション契約またはノーオップガードが必要です。

次のものを測定する刺激は追加しないでください。

• ベースモデルがすでに持っている一般的な知識
• 参照ファイルを示すだけのスキルにおけるパスの想起
• 正確さではなく出力量
• 既存ケースの名前を変更したもの、または表現を少し変えただけのもの
• 単独での disable-model-invocation: true を持つ参照スキル

提案する各ケースを、能力、リスク、カスタマージャーニーのタグに対応付けます。選好ケースは、それぞれ固有の投票価値を加える必要があります。アクティベーション契約とノーオップガードは、別個のルーティングまたは維持に関する不変条件を保護する場合、同じ能力を共有してもかまいません。入力、期待される結果、失敗モード、採点者の経路が同じケースが 2 つある場合は、より強い方を残します。5 つの刺激という最低数を、かさ増しの正当化にしてはいけません。

次に、対象とテストディレクトリを見つけます。

tests/<plugin>/<skill-name>/eval.yaml          # skills
tests/<plugin>/agent.<agent-name>/eval.yaml    # agents (the agent. prefix disambiguates)
tests/agentic-workflows/<package>/eval.yaml   # redistributable gh-aw packages

対象が plugins/<plugin>/skills/<skill-name>/SKILL.md または plugins/<plugin>/agents/<agent-name>.agent.md に存在することを確認し、その内容を読みます。

エージェント評価ではネイティブ SDK エージェントレーンを使用します。 Vally 0.14 ではカスタムエージェントを登録できないため、agent.* 仕様はスキル実験を通じて実行されません。評価ワークフローはこれらを別途検出し、skill-validator evaluate を通じて対象エージェントを実行して得られた証拠を、同じスキーマバージョン付きの結果およびダッシュボードのパイプラインに適合させます。固有の刺激に関する最低数は、スキル評価とエージェント評価の両方に適用されます。

disable-model-invocation: true を設定したスキルには注意してください。 モデルはそのスキルを呼び出せないため、モデルに公開されるスキル有効化側には含まれず、直接評価では同一の 2 つの側を比較することになります。回答内容の採点者を使っても、両側に差は生まれません。このようなスキルの適切なカバレッジは依存関係レベルで確保します。つまり、そのスキルを読み込むスキルの結果評価と、プラグイン側を通じてカバーします。たとえば、filter-syntax は tests/dotnet-test/run-tests/eval.yaml のフィルター付きコマンドのシナリオでカバーされています。

ステップ 2：仕様の骨組みを書く

仕様は Vally 形式です。このリポジトリのすべての評価では stimuli: と graders: を使用します。scenarios: と assertions: は古い Vally 形式であり、現在は読み込まれません。

name: <skill-name>
description: Evaluates the <plugin>/<skill-name> skill
type: capability
defaults:
  timeout: 5m
  runs: 1
stimuli:
  - name: <what the agent must accomplish>
    prompt: <natural developer request>
    tags:
      capability: <distinct-capability>
      risk: <failure-being-prevented>
      journey: <customer-task>
    environment:
      files:
        - src: fixtures/<case>/Project.csproj
          dest: Project.csproj
    graders:
      - type: output-matches
        config:
          pattern: (root cause|underlying issue)
      - type: exit-success
      - type: prompt
    rubric:
      - <outcome the agent should have reached>

defaults: のみを使用してください。 config: は非推奨のエイリアスであり、リポジトリのゲートで拒否されます。エイリアスだけが記述されていると Vally は警告し、両方のキーが仕様で宣言されているとエラーをスローします。config: を 1 つの defaults: ブロックに置き換え、その設定を維持してください。

ステップ 3：内容を書く前に、検出力を確保できる規模に評価を設定する

ゲートでは、それぞれ異なる刺激に 1 票を与えます。同じ刺激に対する複数回の実行は、1 つの多数方向の票にまとめられ、信頼性を示す証拠として引き続き利用できます。

1. 異なる刺激が 5 つ以上でなければ、判定は underpowered となります。合格にも回帰にもなりません。
2. 同点でない不一致の刺激票を対象とする、正確な片側符号検定で p ≤ 0.05。 同点は除外されず、不一致数を減らします。

不一致の刺激票	合格となる記録	p
≤ 4	なし	≥ 0.0625
5–7	敗北がない場合のみ（5W/0L）	0.031
8	敗北 1 件まで許容（7W/1L）	0.035

刺激がちょうど 5 つの場合、同点が 1 つあると不一致票が 4 つになるため、致命的です。刺激が 6 つなら同点が 1 つあっても許容され、7 つなら最大 2 つまで許容されます。敗北は許容されません。5 は適格性の下限であり、十分な検出力を確保できる数ではありません。たとえば、真の条件付き勝率が 90% の場合、検出力 80% に必要な不一致票は 8 つです。勝率が 80% なら 18、70% なら 37、60% なら 158 必要です。検出したい効果と同点率に合わせて規模を設定してください。

runs はタスクの幅ではなく、信頼性のために使用してください。Vally は、合格率、pass@k、pass^k、フレーキネスを測るため、CI では 3 回、夜間実行では 5～10 回を推奨しています。実行回数を増やしても、刺激が 5 つ以上という下限は満たせません。

dotnet-skills.experiment.yaml では runs を設定しないでください。実験のオーバーライドは、各評価の設定値をデフォルト値にするのではなく、すべて上書きします。

ステップ 4：刺激を書く

• 名前には、テスト対象の「内容」を記述します。「方法」ではありません。
• プロンプトは、開発者が自然に依頼する内容にします。スキル、エージェント、またはその語彙には決して言及しないでください。手がかりを含むプロンプトは、過学習のスコアを不当に押し上げ、ベースラインに偏りを生じさせます。
• 各刺激で、スキルの異なる特性を判別できるようにします。1 つの特性を対象とする刺激を 5 つ用意しても、得られるのは算術的な結果であり、証拠にはなりません。
• 能力に関する刺激には、空でない capability、risk、journey タグをすべて付与します。安定した小文字のケバブケース値を使用してください。有用な構成では、このマトリックスの異なる行や列を組み合わせます。表現をわずかに変えただけの同じ journey を繰り返す構成にはしません。
• すべての刺激に、安定した一意の name を付けます。Vally は比較対象のトラジェクトリを (stimulus name, trial index) で対応付けます。名前が重複すると、スロットの識別が曖昧になります。
• コードを移行または書き換えるスキルには、境界条件または何もしない刺激を含め、すでに正しい入力を変更しないことを証明します。
• 実際のルーティング境界ごとに、休眠状態を確認する刺激を追加します。何もしない刺激は、対象となる、すでに正しい入力に対して変更を控えることを証明します。休眠状態を確認する刺激は、対象外の依頼に対して対象が動作しないことを証明します。

ステップ 5：環境を設定する

environment:
  files:
    - src: fixtures/broken-build/App.csproj      # path relative to eval.yaml
      dest: App.csproj                           # path in the agent's working directory
    - src: fixtures/broken-build                 # a directory
      dest: .
  commands:
    - dotnet build -bl || exit 0                 # guard intentional failures

スキル評価では environment.skills を設定しないでください。 実験では vary: /environment/skills を宣言し、値も実験自体が指定します。ベースラインアームでは []、スキルありアームでは plugins/<plugin>/skills/<skill> が指定されるため、評価で宣言した値は すべてのアームで置き換えられます。評価の設定だけで一方のアームにスキルを追加することはできません。 environment.skills に意味があるのは agent.* 評価の場合です。ネイティブエージェントのレーンでは、 分離されたターゲット実行時にのみそれらのエントリーが読み込まれます。一方、プラグイン実行では、 本番プラグインのスキル全体が読み込まれます。記憶を頼りに形式を再現するのではなく、 tests/dotnet-test/agent.test-quality-auditor/eval.yaml など、既存のエージェント評価から形式をコピーしてください。 このリポジトリ内の仕様では、エントリーの記述方法に一貫性がありません。

フィクスチャのルール — いずれも、実際に結果へ影響したことがあります。

• 参照するフィクスチャはすべて git で追跡されている必要があります。 .gitignore（例：coverage*.xml）に コミット済みのフィクスチャが気付かないうちに除外され、評価がローカルでは成功する一方、 CI ではセットアップ時に失敗しました。作業ツリーを見るのではなく、git ls-files で確認してください。
• 各フィクスチャは、刺激が想定する挙動をする必要があります。 正常な状態を想定したフィクスチャはビルドでき、 壊れた状態を想定したフィクスチャは、刺激の対象となる理由そのものによって失敗し、それ以外の理由では失敗しない 必要があります。フィクスチャ作成者が持ち込んだ無関係な「既存のビルド問題」によって、エージェントが減点されることがあります。
• 各フィクスチャは、刺激の名前の由来となったバグを再現する必要があります。 再現できない場合、 ベースラインのスコアが高くなり、スキルに付加できるものがありません。
• カバレッジのフィクスチャでは、内部の整合性を保つ必要があります。 宣言された line-rate、サマリーの合計（lines-covered／lines-valid）、<line> 要素が一致しない Cobertura レポートでは、 2 つのアームが異なる事実を読み取ることになり、その損失はフィクスチャの責任です。同じ変更で、 数値を引用しているルーブリック項目やプロンプトも更新してください。
• n を増やすために、重複したフィクスチャを組み込まないでください。 残り物の名前を変えても、根拠のない試行が増えるだけです。
• 成果物は生成するものの失敗することが想定されるセットアップコマンドには、|| exit 0 を付けてください。 そうしないと、vally によってその試行が破棄されます。
• ソースを削除するクリーンアップコマンドでは、SKILL.md を含むディレクトリを対象外にしてください。 ステージされたスキルはそこにあり、削除するとスキルありアームだけが中断されます。
• ファイル一式を完全な状態で保ってください。 プロンプトで編集を制限したり、ソース／テストの保持を求めたりする場合は、 代表的なファイルだけでなく、対象範囲内のすべてのファイルをスナップショットまたは比較してください。 主な出力だけを確認する採点システムでは、兄弟ファイルの削除、切り詰め、編集を見逃す可能性があります。

ステップ 6：採点基準を書く

採点基準は、各アームで評価される合否判定です。

種類	必須の設定	目的
output-matches / output-not-matches	pattern	エージェントの出力に対する正規表現
output-contains / output-not-contains	substring	出力内のリテラルテキスト
file-exists / file-not-exists	path	作業ディレクトリに対する glob
file-contains / file-not-contains	path、value	生成されたファイルの内容
run-command	command（任意で expected_exit_code、timeout、stdout_matches を追加）	生成されたコードが実際にビルド／実行できることを検証
exit-success	—	エージェントが空でない出力を生成したこと
prompt	—	rubric に基づいて LLM の判定者を実行

ルール：

• config が存在しない、または必須キーが欠けている採点基準は問題なく解析されますが、何も強制しません。 通常の原因は編集時のインデントミスです。check_eval_quality.py がこれをブロックします。
• 複数の妥当なアプローチで満たせる、広範なパターンを優先します： (root cause|primary error|underlying issue)。
• スキルが出力形式を必須としている場合は、その形式を検証してください。 決定的な Recommendation: 行の出力を求めるスキルで、それがひそかに出力されなくなっても、評価が通ってしまうことがあります。
• エージェントが誤った操作を避けたことを証明するには、file-not-contains / file-not-exists を使用します。

プロンプト採点基準を書く前に、決定論的な契約を定義します：

1. ゴールデンの受け入れ： フィクスチャを展開し、該当する場合は golden_patch を適用します。ゴールデンのワークスペースと最終的な golden_trajectory の応答は、適用されるすべての決定論的な採点基準を満たす必要があります。
2. 変更の検出： 評価で検出する現実的な不具合を 1 つ作ります。たとえば、ファイルの欠落、検出されたテストが 0 件、対象範囲外の編集、意味のある値の変更などです。該当する決定論的な採点基準は失敗する必要があります。
3. 完全な状態の確認： 依頼に記載されたすべてのファイルと成果物を網羅します。肯定的な部分文字列が 1 つあるだけで、不完全な成果物を受け入れてはいけません。

再現可能なワークスペースの状態には golden_patch を、期待する最終応答には golden_trajectory を使用します。編集、ビルド、テストを説明しただけでは証拠になりません。完了したという主張には、パッチか、証拠を再実行する run-command 採点基準が必要です。

ステップ 7：ルーブリック項目を書く

ルーブリック項目はペア単位（ベースライン対スキル習得済み）で評価されます。過剰適合を判定する評価器は、各項目を次のように分類します：

分類	説明	目標
結果	エージェントが正しい結果に到達したかどうか — 方法ではなく、何を達成したか	これを対象にする
手法	エージェントがスキル固有の手順を使ったかどうか	最小限にする
用語	エージェントがスキルの用語を使ったかどうか	避ける

1. 手法ではなく結果を評価します：「ビルド失敗の根本原因を特定した」であり、「dotnet build /flp を使って binlog を再生した」ではありません。
2. 妥当なアプローチはすべて受け入れます。
3. スキルの名前を参照せず、SKILL.md の言い回しを再利用しないでください。
4. スキルを使用したことを評価してはいけません。ハーネスが有効化を別途報告するため、それを評価するルーブリック項目は何も測定せず、過剰適合スコアを水増しします。
5. モデルがすでに持っている知識を評価しないでください。差分が生まれません。
6. 各項目は個別に評価できるようにします。
7. 単純な量（テスト件数、レポートの長さ）を評価しないでください。両方のアームが行動する場合、判定者はそれを比較します。

良い例：

rubric:
  - Correctly identified the missing NuGet package as the root cause of the build failure
  - Recognized that downstream failures cascaded from that root cause
  - Suggested a concrete fix that resolves it

過剰適合した例：

rubric:
  - Replayed the binary log using 'dotnet build /flp:v=diag'   # technique
  - Measured cold, warm, and no-op build scenarios             # vocabulary
  - Used the template-comparison skill                         # rewards activation

ステップ 8：制約は必要最小限にする

constraints:
  expect_tools: [bash]
  reject_tools: [edit, create]
  reject_skills: [some-skill]

• 助言的な質問に expect_tools: [bash] を指定すると、復元やビルドが強制され、品質向上の効果がないまま回答がタイムアウトに変わります。タスクで本当に必要な場合にのみ、ツールを必須にしてください。
• 読み取り専用の刺激を読み取り専用に保つには、reject_tools を使用します。

ステップ 9：休眠ガードを追加する

休眠ガードは、表面的にはスキルに一致するものの、対象外のリクエストに対してスキルが休眠状態を保つことを検証します。「使用しない場合」に該当する実際の境界ごとに 1 つ追加します。入力形式が誤っている場合、対象範囲外のリクエスト、互換性のないプロジェクト種別、誤ったフレームワークのバージョン、前提条件が満たされていない場合などです。

  - name: Decline dump analysis request
    prompt: |
      I already have a .dmp crash dump from my .NET app. Can you help me
      analyze it to find the root cause of the crash?
    expect_activation: false
    graders:
      - type: output-matches
        config:
          pattern: (out of scope|not cover|does not|cannot|only.*collect)
      - type: prompt
    rubric:
      - Stated that dump analysis is out of scope
      - Did not open or analyze the dump file
      - Did not install analysis tools such as dotnet-dump analyze, lldb, or windbg
      - Suggested the correct alternative

expect_activation: false と constraints.reject_skills は決して組み合わせないでください。 これを行うと、スキルを使用する側の実行もスキルなしで行われるため、ハーネスは対象スキルがリクエストを横取りするかどうかを確認できません。比較はレポート専用の証拠として引き続き表示されますが、優先度の判定には使われません。予期しない単独での有効化があれば、合格にはなりません。expect_activation: false のみを使うのが、このリポジトリの慣例です。

ワークフローパッケージのシナリオ

パッケージを対象とする場合は、agentic-workflows/<package>/aw.yml を確認してから、エントリーワークフロー、ローカルインポート、同梱エージェントを読みます。ネイティブ SDK レーンでは、オフラインのフィクスチャを使って、実際のプロンプト本文とインストール済みリソースを評価します。コレクターの出力、リビジョン／トラッキングの証拠、サービスからの応答はフィクスチャ入力として指定します。ライブの GitHub や安全な出力ツールを使って公開するふりをせず、result.json でターミナルアクションを提案します。構造化された結果は決定論的なグレーダーで検証します。期待される回答を、エージェントが読み取れるフィクスチャやステージングされたグレーダースクリプトに含めないでください。期待値はグレーダーの argv 経由で渡します。

プロンプト式は、フラットな workflow-context.json フィクスチャからレンダリングされます。キーはトリミング済みの式と完全に一致し、値は文字列です。コンテキストが不足している場合、セットアップは失敗します。ワークフローが正しく noop を選択した場合も、expect_activation: false のルーティング証拠ではなく、有効化が期待される判断の証拠として扱います。該当する場合は、通常、部分的、古い、互換性のない、証拠が不足しているケース、および複数モジュールのケースを含めます。コンパイル、ヘルパーの実行、実際のコンシューマーへの公開テストは分離してください。このレーンのラベルは workflow-prompt-sdk であり、エンドツーエンドの Actions 実行ではありません。

dotnet run --project eng/skill-validator/src/SkillValidator.csproj -- evaluate `
  agentic-workflows/<package>/aw.yml `
  --tests-dir tests/agentic-workflows --runs 1 --verdict-warn-only

ガードのルーブリックでは、次の 3 点を検証します。認識（なぜ適用されないか）、抑制（ワークフローを実行せず、ファイルも変更せず、インストールもしないこと）、誘導（次に取るべき正しい手順）。

ステップ 10: 検証

dotnet run --project eng/skill-validator/src/SkillValidator.csproj -- check --plugin ./plugins/<plugin>
python eng/eval-quality/check_eval_quality.py
./eng/run-skill-evals.sh <plugin> <skill-name>

エージェント評価の場合、ネイティブレーンを直接実行します:

dotnet run --project eng/skill-validator/src/SkillValidator.csproj -- evaluate \
  plugins/<plugin>/agents/<agent>.agent.md \
  --tests-dir tests/<plugin> \
  --runs 1 \
  --verdict-warn-only

CI はこの結果を eng/vally-adapter/adapt-agent-results.mjs を通じて適応させ、 これはスキル結果で使用されるものと同じ、異なる刺激に対する符号検定ポリシーを適用します。

検証は次の4つの層をカバーする必要があります:

1. 決定論的な構造: check_eval_quality.py を実行し、チェッカーが変更された場合は 関連するチェッカーのセルフテストを実行します。
2. 本番パースとゴールデンリプレイ: リポジトリの Vally エントリポイントを通じてスキル評価を 実行します。エージェント評価の場合は、skill-validator evaluate を実行して、ネイティブ SDK レーンが 実行可能なシナリオフィールドを受け入れることを証明します。このパーサーは golden_trajectory や golden_patch を読み取らないため、参照は別途検証します: check_eval_quality.py を実行し、次に フィクスチャを実体化して、ゴールデンパッチを適用し、ゴールデンワークスペースに対して適用可能な すべての決定論的なファイルおよびコマンドグレーダーを実行します。最終的なゴールデンレスポンスが その出力グレーダーを通過することを確認します。
3. 通常実行: 通常のワーカー並行度と宣言された defaults.timeout を使用します。1つのワーカーや より大きなアドホックな時間予算だけで評価を認定しないでください。通常の並行度で競合やタイムアウトが 露呈した場合は、それを信頼性のエビデンスとして分類します。
4. クロスファミリー感度: 広範なルーティングや動作の変更については、少なくとも1つの GPT ファミリーと 1つの Claude ファミリーのエグゼキューターを評価します。各結果を個別に報告します。異なるエグゼキューター またはジャッジファミリーは、独立した刺激の数を増やしません。

check_eval_quality.py は、結果を破損させる可能性のある22の構造的欠陥クラスをブロックします: 欠落または未追跡のフィクスチャ、自己矛盾するカバレッジフィクスチャ、空のグレーダー設定、reject_skills を 伴う休止ガード、下限未満の刺激数、重複する YAML キーまたは刺激名、および無効なデフォルト、タグ、 ゴールデンエビデンス、テストコマンド、または ATIF トラジェクトリ。完全なリストについては eng/eval-quality/README.md を参照してください。新しい評価を eng/eval-quality/underpowered-allowlist.txt に追加しないでください — ゲートはベースブランチに対して 新規である allowlist エントリを拒否します。

公式実行では、/evaluate を含む PR レビューを提出して、レビューされたコミットにバインドされるようにします。

検証チェックリスト

• ディレクトリが tests/<plugin>/<skill-name>/ または tests/<plugin>/agent.<agent-name>/ である
• スペックが stimuli: / graders: と現在の defaults: 設定ブロックを使用している
• 選好対象となる異なる刺激が少なくとも5つ存在する; 休止契約はこの下限にカウントされない
• すべての刺激が必要であり、ターゲットに適合している; 各選好ケースが異なる投票価値を追加する
• 各ケイパビリティ刺激が安定した capability、risk、journey タグと一意の名前を持つ
• プロンプトがスキル、エージェント、またはその語彙を決して名指ししない
• 参照されたすべてのフィクスチャが存在し、git ls-files で追跡されている
• すべてのフィクスチャがその刺激の想定どおりに動作する — 健全なものはビルドし、意図的に壊されたものは記載された理由でのみ失敗する
• 保存およびスコープのグレーダーが、スコープ内のファイルセット全体をカバーしている
• すべてのグレーダーが必要な config キーを持っている
• スキルが義務付けるすべての出力形状にグレーダーがある
• ゴールデンエビデンスが決定論的グレーダーを通過し、現実的な変異がそれらを失敗させる
• ルーブリック項目が成果の形をしており、スキルの使用を決して報酬としない
• 書き換えスキルに no-op ケースがある; ルーティング境界は expect_activation: false のみを使用する
• 本番ランナーが実行可能なスペックを受け入れ、通常の並行度と時間制限の下で完了する
• ゴールデン参照がスタンドアロンチェッカーと決定論的リプレイを通過する
• 広範なルーティングや動作の変更に、別個の GPT ファミリーと Claude ファミリーのエビデンスがある
• skill-validator check と check_eval_quality.py が通過する

よくある落とし穴

落とし穴	解決策
scenarios: / assertions: と記述する	この形式は読み込まれなくなりました。stimuli: / graders: を使用してください
非推奨のトップレベル config: エイリアスを使用する	defaults: に変更し、設定をそのまま引き継いでください
刺激をちょうど 5 件にして評価を確定する	1 回でも引き分けがあると合格に到達できません。効果と引き分け率を考慮して件数を設定してください
下限を超えるために runs を増やす	繰り返し実行で測定できるのは、1 つのタスクの信頼性です。刺激を追加してください
プロンプトでスキルやエージェントの名前に言及する	自然な開発者からの依頼になるよう書き換えてください
ルーブリックでスキルの使用を評価する	この項目は削除してください。ハーネスが有効化を別途報告するため、ルーブリックでは成果を測定します
フィクスチャが存在するが、Git に無視されている	git ls-files で確認してください。そうしないと CI のセットアップに失敗します
ビルドできない、または誤った理由で失敗するフィクスチャ	スキルのせいにする前に、フィクスチャを修正してください
reject_skills を使った休眠ガード	expect_activation: false だけを使用してください
アドバイスを求める質問に expect_tools: [bash] を設定する	削除してください。品質ではなくタイムアウトの原因になります
コード生成に対してタイムアウトが短すぎる	約 360 秒に設定してください。出力が空の場合、すべての採点器で失敗します
編集後に YAML キーが重複したままになっている	次の刺激のフィールドを一つずつ上書きします。残ったブロックを削除してください
刺激名が重複している	Vally は名前を比較時の識別子として使用します。各刺激に安定した一意の名前を付けてください
disable-model-invocation: true のスキルを直接評価する	直接評価を削除し、利用側の成果を通じて参照を評価してください
刺激数が下限未満のエージェント評価	ネイティブエージェントアダプターも同じ符号検定ゲートを使用します。選好評価の対象となる独立した刺激を追加してください
./eng/run-skill-evals.sh でエージェント評価を「実行」する	このヘルパーは引き続きスキル専用です。skill-validator evaluate を使用してください
エージェント評価に environment.skills がない	エージェントがルーティングするスキルを宣言してください。宣言しないと呼び出せません
スキル評価で environment.skills を設定する	実験ではそのキーを変化させ、すべてのアームで置き換えます。宣言しても効果はありません