eval-skills

Eval Skills

スキルをテスト対象の関数のように扱います。クリーンルームで入力例を与え、成果物を望ましい結果と照らし合わせ、失敗をもとに修正します。評価が公正であるためには、実行はブラインドでなければなりません。スキルを実行するエージェントは、この会話のコンテキストを一切持たず、期待される出力も決して見てはいけません。どちらかが漏れれば、テストに合わせた学習になってしまいます。

必要な入力 — そろわなければ実行しないでください

何かを起動する前に、次の3つすべてを確認してください。どれかが欠けている、または特定できない場合は、そこで止めて、どれが欠けているのか、良い入力の例はどのようなものかをユーザーに正確に伝えてください。ケースを作り上げたり、意図を推測したり、曖昧な要望に対して評価したりしてはいけません。

• 対象のスキル — 実在する SKILL.md を特定できる必要があります。見つからない場合は、確認できるスキルを一覧表示し、どれを指しているのか尋ねてください。
• ゴールデンケースが少なくとも1つ — スキルが実際に受け取る具体的な入力です。スクリーンショット、プロンプト、ファイル、シーンなどが該当します。入力が添付されていない「write-spec を改善して」という依頼はケースではありません。
• ケースごとの合格基準 — 良い成果物がどのような結果を実現するか、また悪い成果物に見られる兆候は何かを示してください。項目を網羅的に列挙する必要はありません。テスト対象はスキルの判断力なので、要件を一つ残らず事前に列挙してはいけません。それでは評価が適合性チェックになり、スキルが適切に判断できるかをテストできなくなります。「各ピースが単独で構築・検証できるよう、熟練者が選ぶ粒度で分割されていること。大きすぎる分割も、無意味な細分化も失敗とする」は、評価者が成果物を判定できる基準です。「うまく分割すること」では基準が曖昧すぎて評価できず、期待する分割の固定リストでは細かく指定しすぎです。基準と悪い兆候を示し、評価者に判定を委ねてください。例外は、厳密に指定したタスクをそのとおり実行することが本質的な適合性重視のスキルです。その場合は、明示的な基準そのものが合格基準になります。基準の形はスキルの性質に合わせてください。どちらに当たるか判断できない場合は、質問してください。ユーザーの依頼が曖昧で合格基準もない場合は、エージェントを起動する前に基準を引き出し、それをユーザーに言い返して確認してください。

ワークフロー

1. 入力を検証し、第一原則を明確にします。 スキルを特定して、その第一原則、つまり何のためのもので、どのような基準を掲げているのかを確認します。判定者がこれを基準に評価するため、スキルで明確になっていない場合は、独自に作り上げずユーザーに確認してください。ここで評価モードも決めます。判定者が適用する基準に照らす「判断」なのか、指定されたタスクに厳密に従う「適合」なのかです。曖昧な場合はユーザーに尋ねてください。次に、各ケースの基準を明確にします。結果と問題の兆候を、ユーザーが重視する粒度に保ちます。スキルが適合形式でない限り、所定の部品一覧へと広げてはいけません。スキルの第一原則を一文で述べられ、すべてのケースに具体的な入力と、適格な判定者が成果物を評価できる基準がある状態になれば完了です。

2. ブラインド実行を行い、ケースごとに新しいエージェントを使います。 実行をそれぞれ分離し、問題のあるスキルが現在のチェックアウトに触れないようにし、各ケースをクリーンな状態から始めます。可能なら、ランナーの最終メッセージから成果物を取得します。スキルの出力が計画やテキストなら、インラインで出力するよう依頼し、漏えいにつながるファイルをディスクに残さないようにします。スキルがファイルを書き込む必要がある場合は、ランナーに使い捨てのサンドボックスディレクトリだけを唯一の書き込み可能なルートとして渡し、現在のリポジトリのワークツリーは使いません（ワークツリーによる分離で保護されるのは Git の状態であり、絶対パスやルート外への書き込みではありません）。実行のたびに現在のチェックアウトを確認し（git status）、実行によって漏れたものがあれば削除します。分離はベストエフォートであり、保証となるのは確認です。ランナーには入力と対象スキルを使う指示だけを渡してください。基準、問題の兆候、他のケース、質問の理由は決して伝えてはいけません。コンテキストのない実行から得た成果物がケースごとに1つずつ揃い、チェックアウトがクリーンな状態になれば完了です。

3. 判断を行う別の判定者が評価します。 新しい判定者に、成果物、基準、スキルの第一原則を渡します。こうすることで、判定者個人の好みではなく、スキル自体の意図に照らして評価できます。ただし、期待される出力や「これに合格させて」という指示は決して渡しません。判定者は第一原則を踏まえた熟練者として、根拠を示せる選択で基準を満たしているかを判断します。また、粗すぎる成果物も細かすぎる成果物も、明示的に問題として指摘できます。各判定の根拠として、数値ではなく、引用や該当箇所を示す必要があります。基準の各項目について、成果物に根拠を持つ判定ができれば完了です。

4. 非決定性を考慮します。 エージェントの結果は揺らぎます。1回の合格だけでは証明になりません。重要なケースや判定が境界線上に見えるケースでは、ブラインド実行を2～3回繰り返し、合格率を報告します。3回中1回しか合格しないスキルは、修正済みとはいえません。

5. 各失敗をスキルの欠陥か、ケースの不備かに診断します。 失敗の原因は、スキルが期待する振る舞いを促せなかった（ここで修正可能）か、基準が誤っていた（スキルがすべきでないこと、表現できないことを求めていた、または妥当な判断を罰していた）のどちらかです。後者の場合はユーザーに伝えてください。誤った基準を追いかけるようスキルを編集してはいけません。それは誤った現実をそのまま組み込むことになります。write-skills の失敗モードに照らして欠陥を名付けます。 早すぎる完了、曖昧な完了条件、ルールの欠落、先導語の欠落、重複、堆積、武勇伝、何もしないこと。

6. write-skills を使って修正します。 特定した欠陥を修正し、その際は執筆ルールにも従います。まず完了条件を明確にしてから内容を追加し、文を増やすより先導語を1つ使うことを優先し、何もしない指示は追加しません。失敗を編集の仕様とし、失敗が示す箇所だけを変更します。

7. 失敗したケースだけでなく、すべてのケースを再評価します。 修正によって、合格していたケースが後退する可能性があります。すべてのケースが合格率の基準を満たすまで、またはスキルの構造上あるケースを表現できないと示せるまで繰り返します。表現できない場合は、無理に対応させず、その旨を報告します。

出力

ケースごとの合格率と指摘された不足点、各失敗に対応する欠陥、実施した修正（または、ユーザーが事前承認を求めた場合は、提案する差分）、再評価の結果をまとめた短いレポートです。修正前後の変化がわかるようにしてください。これが、スキルが実際に改善したことを示す証拠です。

ルール

• ブラインド評価は必須です。 ランナーには入力だけを見せます。評価者には成果物と基準、そしてスキルの基本原則を見せます。どちらかが期待される出力を見た時点で、評価は無意味になります。
• 適合性ではなく判断力を評価してください。 基準は、作業が満たすべき標準であり、回答のチェックリストではありません。期待する具体的な要素を列挙し始めたら、スキルの評価ではなくなっています。
• 分離は可能な限り行い、最終チェックで保証してください。 実行後は必ず現在のチェックアウトを確認し、実行がどのようにサンドボックス化されていたかにかかわらず、漏れがあればクリーンアップしてください。
• 実行ごとにケースごとに新しいエージェントを1つ使用します。コンテキストを共有しないようにすることで、ケース間の学習によって後続ケースの評価が不当に向上するのを防ぎます。
• 他の成果物と比較するのではなく、基準に照らして評価してください。また、基準のどの部分に不合格だったかがわからなくなるような数値スコアで評価しないでください。
• 擁護できないケースに合格させるために、スキルを曲げないでください。基準の不備を明らかにする失敗ケースは、バグではなく知見です。