create-skill-test

create-skill-test skill の概要

create-skill-test は、dotnet/skills リポジトリでエージェント用スキルの eval.yaml テストファイルを作るための、足場作成と検証を支援するツールです。目的は「テストを書いて」といった一般的なプロンプトではなく、スキルテストのための信頼できる出発点が必要な人に向けたものです。主な役割は、対象スキル、プラグイン名、シナリオ案を、慣例に沿った安全なテスト構造に変換し、fixture、assertion、rubric を過度に特定実装へ寄せずに組み立てることです。

create-skill-test は、どのスキルを評価したいかはすでに分かっていて、リポジトリのルールに合うテストファイルを素早く作りたい作者に最適です。テストを実行したいだけのとき、validator の失敗をデバッグしたいとき、あるいは SKILL.md をゼロから書きたいときには、あまり向いていません。

create-skill-test は何のためのものか

新しい eval ファイルを作るとき、既存の eval にシナリオを追加するとき、あるいは rubric がたった 1 つの出力例にだけ強く依存していないか確認したいときに、create-skill-test を使います。テスト設計の品質が YAML の形と同じくらい重要な create-skill-test for Skill Testing のワークフローでは、とくに有効です。

何を避ける助けになるか

最大の価値は、壊れやすい eval を避けられることです。具体的には、必須フィールドの欠落、skill path の不一致、fixture の整理不足、そして実際の挙動ではなく言い回しだけを評価してしまう rubric の文言などです。対象スキルが進化してもテストを有用に保ちたいなら、ここは重要です。

何を置き換えないか

skill-validator の代わりにはなりませんし、SKILL.md ファイルの編集を助けるものでもありません。壊れたテスト実行の原因を特定したい、あるいは validator の出力をデバッグしたいなら、これは使うべきツールではありません。

create-skill-test skill の使い方

インストールして元スキルを開く

npx skills add dotnet/skills --skill create-skill-test で create-skill-test をインストールします。次に最初に SKILL.md を読みます。モデルに何かを生成させる前に、ワークフロー、入力要件、そして依頼が有効かどうかを決める境界条件がそこに書かれているからです。

適切なテストブリーフを与える

強い create-skill-test install の依頼は、単に「テストを作って」ではありません。スキル名、プラグイン名、検証したい挙動、シナリオ上の制約を含めてください。スキルは plugins/<plugin>/skills/ 配下にある対象を前提にしているため、名前の正確さが重要です。

より良いブリーフの例は次のとおりです。

• Skill: foo-bar
• Plugin: dotnet-msbuild
• Goal: エージェントが有効な summary を作成し、未対応の path を拒否することを確認する
• Scenario: 初回利用者で、前提情報が一部しかない
• Fixture need: 最小構成の入力ファイル 1 つと、エッジケース用ファイル 1 つ

これだけの構造があれば、create-skill-test usage の流れは、ただの一般的な eval ではなく、実用的なものを組み立てやすくなります。

重要なリポジトリの節を読む

まず SKILL.md を読み、その後に README.md、AGENTS.md、metadata.json、さらに近くに rules/、resources/、references/、scripts/ フォルダがあれば、それらも確認してください。このリポジトリのスナップショットでは表示されているのが SKILL.md だけなので、skill 定義そのものが主な一次情報になります。

シナリオと rubric を反復調整する

最初の下書きで、テストが本当に意図した挙動を測れているか確認します。rubric が文言を褒めるだけで結果を見ていないなら、基準を絞ってください。シナリオが広すぎるなら分割してください。スキルに本当に必要なのが 1 つの成功経路だけなら、余計なケースを作らず、eval は小さく保つほうがよいです。

create-skill-test skill の FAQ

create-skill-test は dotnet/skills 専用ですか？

はい、dotnet/skills リポジトリの慣例と plugins/<plugin>/skills/ 配置を前提に設計されています。ほかの場所にも応用はできますが、リポジトリ構造と validation の期待値が同じときに、create-skill-test のガイドは最も価値を発揮します。

普通のプロンプトの代わりに使うべきですか？

再現性のある eval の足場を作り、構造上のミスを減らしたいなら create-skill-test を使ってください。普通のプロンプトでもテスト内容は説明できますが、リポジトリ固有の慣例、fixture の置き場所、過剰適合のチェックについては、たいてい弱くなります。

初心者にも向いていますか？

はい。対象スキルを特定できて、シナリオを平易な言葉で説明できるなら使えます。逆に、プラグイン名、スキルの path、検証したい挙動を言えない場合は初心者向けとは言いにくいです。というのも、それらの入力が生成結果を直接左右するからです。

どんなときに使わないほうがいいですか？

テストの実行、validator エラーのデバッグ、新しい skill の作成には使わないでください。これらは隣接するワークフローですが、使うツールも成功条件も異なります。

create-skill-test skill を改善する方法

入力をもっと絞る

create-skill-test の成果がよくなるのは、広い意図よりも具体的なシナリオを与えたときです。「コンテキスト不足を処理して安全な fallback を返すことをテストしたい」は、「包括的な eval を作ってほしい」よりもはるかに強い指示です。なぜなら、どの挙動が重要で、何を過剰に評価してはいけないかがはっきりするからです。

YAML だけでなく rubric の質も求める

構造だけを頼むと、形式上は正しくても過剰適合したファイルが返ることがあります。何を成功とみなすのか、何を失敗とみなすのか、どの詳細が本質的でどれが付随的なのかを明示してください。それが create-skill-test for Skill Testing の結果を最短で改善する方法です。

生成後に過剰適合を確認する

assertion が、1 つの言い回し、固定順序、あるいは完全一致の例文だけを評価していないか確認してください。そうした細かさが本当に必要な場合を除き、良い eval は 1 回の実行で出た文言そのものではなく、スキルが維持すべき挙動を測ります。

validator のフィードバックで絞り込む

最初の出力が validation に失敗したら、正確なエラー内容とその周辺の YAML 断片をそのまま返してください。たいていは、依頼全体を言い直すよりも、その情報を使った 2 回目の出力のほうがよくなります。