evaluation-methodology

evaluation-methodology スキルの概要

evaluation-methodology スキルでできること

evaluation-methodology スキルは、Model Evaluation における PluginEval の採点体系を解説するためのスキルです。一般的な「モデルをどう評価するか」を教えるプロンプトではありません。プラグインやスキルの品質を評価する際に使われる、3つの評価レイヤー、採点ディメンション、ブレンドロジック、複合スコア、バッジ閾値、アンチパターンのフラグ、ランキングの考え方までをカバーする、特定の方法論リファレンスです。

evaluation-methodology を導入すべき人

このスキルは、単にスコアを1つ出したい人よりも、評価結果を解釈したり改善につなげたりしたい人に向いています。特に相性がよいのは次のようなケースです。

• 低いスコアの原因を切り分けたいスキル作者・プラグイン作者
• 品質ゲートを調整したいマーケットプレイス運営者・プラットフォーム運営者
• スコアをめぐる認識差や異議対応で、一貫した説明言語が必要なレビュアー
• バッジやランキングの意味をパートナーや社内関係者に説明するチーム

実際の課題が「なぜこのスコアになったのか」「まず何を直すべきか」を明らかにすることなら、evaluation-methodology はかなり有力な選択肢です。

実際に解決したい仕事

導入前に多くのユーザーが気にするのは、だいたい次の4点です。

1. どのディメンションが特に重要なのか
2. 静的チェックと judge ベースの採点はどう違うのか
3. Monte Carlo やブレンドされた各レイヤーが最終スコアにどう効くのか
4. どんな変更をすれば最短でスコアが上がるのか

evaluation-methodology スキルの価値は、こうした疑問に対して、散在した rubric の断片から推測させるのではなく、構造化された形で答えを返せる点にあります。

通常の評価プロンプトとの違い

一般的なプロンプトでも、LLM に「このスキルを評価して」と頼むこと自体はできます。ただし、通常は次の要素が不足しがちです。

• レイヤーごとの明確な分離
• 根拠となる rubric 参照
• ディメンション別の重み付けロジック
• 閾値やバッジの解釈
• キャリブレーションや異議対応に使える方法論の言葉づかい

特に Triggering Accuracy、Orchestration Fitness、スコア解釈のように、評価理由の一貫性が重要な場面では、このスキルのほうが適しています。

判断前に読むべきファイル

まず SKILL.md を読んで評価手法の全体像をつかみ、次に references/rubrics.md で judge レイヤーが依拠する基準を確認してください。evaluation-methodology スキルが自分の Model Evaluation ワークフローに合うかどうかは、この2ファイルで十分に判断できます。

evaluation-methodology スキルの使い方

evaluation-methodology の導入方法

リポジトリからのインストールは次のコマンドです。

npx skills add https://github.com/wshobson/agents --skill evaluation-methodology

導入後は、ほかのインストール済みスキルと同じように、AI コーディング環境から呼び出せます。PluginEval のスコア解釈、方法論の説明、キャリブレーションの支援、スコア改善の助言を明示したタスクとして依頼するのが基本です。

このスキルに必要な入力

evaluation-methodology スキルは、次のような具体的な評価コンテキストがあると最も機能します。

• 評価対象となる SKILL.md またはプラグインの内容
• 不自然に見えるディメンションやスコア
• 静的解析を見たいのか、LLM judge の出力を見たいのか、ブレンド後の総合スコアを見たいのか
• 目的が説明・調整・改善・弁護のどれか
• 自分たちが運用している marketplace の閾値、badge cutoff、合格基準

こうした前提がないと、方法論自体の対象範囲が広いため、出力も抽象度の高い説明にとどまりやすくなります。

あいまいな依頼を強いプロンプトに変える

弱いプロンプト:

Explain this evaluation score.

より強いプロンプト:

Use the evaluation-methodology skill to interpret this PluginEval result. Focus on Triggering Accuracy and Orchestration Fitness, explain how the three evaluation layers likely contributed, identify which issues are static-document problems versus judge-layer reasoning problems, and suggest the smallest changes that would most improve the composite score.

この聞き方が有効な理由は次のとおりです。

• 方法論を明示的に指定している
• 対象ディメンションを絞っている
• レイヤーを意識した説明を求めている
• 単なる要約ではなく、優先度付きの改善案を求めている

evaluation-methodology の活用で使いやすいプロンプト型

質の高い evaluation-methodology usage プロンプトには、通常次の4点が入ります。

1. 評価対象の成果物
2. 問題になっているスコアまたはディメンション
3. その評価をもとに下したい判断
4. 欲しい出力形式

例:

Apply the evaluation-methodology skill to this skill draft. Estimate which dimensions are most at risk, cite the likely rubric anchors behind that judgment, and recommend edits that improve triggering precision without making the description too narrow.

推測を減らせる実践的な進め方

次の順で進めると、見当違いを減らせます。

1. SKILL.md を読んで採点体系の全体像を把握する
2. references/rubrics.md を開いて anchor レベルの解釈を確認する
3. 実際に手を打つべきディメンションを特定する
4. レイヤー別の診断を依頼する
5. スキルまたはプラグインを修正する
6. 変更で文書が長くなっただけではなく、本当に狙ったディメンションが改善したかを再確認する

これは重要です。多くのスコア問題は、原因の見立てがずれています。たとえば triggering の問題は frontmatter の説明文が曖昧なことから起きやすく、orchestration の問題は入出力契約が不明確なことから起きる場合があります。

先に読むべきリポジトリ内ファイル

この evaluation-methodology guide を見るなら、まず優先したいのは次のファイルです。

• plugins/plugin-eval/skills/evaluation-methodology/SKILL.md
• plugins/plugin-eval/skills/evaluation-methodology/references/rubrics.md

全体フレームワークの理解には SKILL.md、スコアの根拠をより具体的に読み解いたり、ドラフトを anchor point と照らし合わせたりしたいときは references/rubrics.md を使うのがよいです。

3つのレイヤーを実務でどう見るか

この方法論は、3つのレイヤーを積み上げる形になっています。

• 決定的な文書チェックを行う static analysis
• rubric ベースの定性的評価を行う LLM judge scoring
• 特に triggering を中心に、プロンプト分布上の挙動を見る Monte Carlo simulation

この分離は実務上かなり有用です。公開前にまず雑な不備がないかを素早く見たいなら、最初に見るべきは static analysis です。低スコアの理由を説明可能な形で整理したいなら、judge rubric の重みが増します。現実的にばらつきのあるプロンプトに対して、スキルが適切に発火するかを知りたいなら、意思決定に最も直結するのは Monte Carlo の見方です。

Model Evaluation で evaluation-methodology を使うべき場面

evaluation-methodology for Model Evaluation が有効なのは、単なるモデル出力の良し悪しではなく、そのモデル挙動を包むスキルやプラグインの品質を見たいときです。とくに、スキルが見つけられやすいか、適切なタイミングで発火するか、足場となる説明や構造が整っているか、エージェントの生態系の中で運用上信頼できるか、といった論点では相性がよいです。

一方で、プラグインやスキルのオーケストレーションとは無関係な、純粋なモデル性能ベンチマーク設計だけが目的なら、この方法論はあまり向いていません。

導入時によくある迷い

「これは実際に改善に使えるのか、それとも説明用なのか」が、導入時によくある迷いです。実際には、次の目的なら十分に実用的です。

• スコアをディメンションまでさかのぼって追いたい
• 各ディメンションが何を評価しているか理解したい
• 複合スコアに効く修正を選びたい
• 公開やバッジ付与の閾値を調整したい

逆に、すぐ動く評価スクリプトのようなものを期待しているなら、期待はずれになる可能性があります。このリポジトリで強いのは実装済み自動化ではなく、方法論と rubric を文章でしっかり定義している点です。

evaluation-methodology スキル FAQ

evaluation-methodology は採点ツールですか、それとも方法論リファレンスですか？

主軸は方法論リファレンスです。PluginEval がどう品質を測り、結果をどう読むべきかを示してくれます。そのため、監査、キャリブレーション、改善計画には特に役立ちます。

evaluation-methodology スキルは初心者向けですか？

はい。ただし、少なくともスキルやプラグインが何かを理解している初心者向けです。文章構成自体は整理されていますが、いきなり全体フレームワークをまとめて読むより、実例を持ち込み、1回につき1ディメンションずつ尋ねたほうが理解しやすくなります。

LLM に自分のスキルをレビューさせるのと何が違いますか？

通常のレビュー用プロンプトでも、そこそこ有益な助言は返ってきます。ただし、PluginEval のレイヤー構造や rubric anchor に沿った評価にはなりにくいのが実情です。evaluation-methodology skill は、複数のレビュアー間で評価の言葉をそろえたいときに効く、共通の採点言語を提供してくれます。

evaluation-methodology を使わないほうがよいのはどんなときですか？

次のような場合は見送って問題ありません。

• 一般的な文章レビューだけが欲しい
• 評価したいのが skill/plugin の品質ではなく、生のモデルタスク精度である
• 方法論のガイドより、実行可能な自動化を求めている
• 自分たちのエコシステムが PluginEval に近いディメンション設計や badge logic を採っていない

Triggering Accuracy の低スコア対策にも使えますか？

はい。rubric の参照では、triggering を代表的なプロンプト集合に対する precision と recall の両面で扱っています。説明文が曖昧すぎて安定して発火しない場合にも、逆に広すぎて関係ないプロンプトで発火してしまう場合にも、特に有効です。

PluginEval 以外でも使えますか？

はい。ただし主に、構造化された参照モデルとして使う形になります。ディメンション設計、レイヤー分離、rubric 的な考え方は他の文脈にも移しやすいです。一方で、重み、閾値、バッジの定義そのものは、運用プロセスが PluginEval に近い場合に最も活きます。

evaluation-methodology スキルを改善するには

まずは判断に効くディメンションから見る

evaluation-methodology スキルを使うとき、最初から「全体品質」を聞かないでください。まずは「どの単一ディメンションが意思決定のボトルネックになっているか」を聞くほうが有効です。実務上は、特に Triggering Accuracy や Orchestration Fitness で、改善余地の大きい論点が早く見つかりやすくなります。

より良い分析のために入力を強くする

入力として望ましいもの:

• 現在のスコア、または弱いと疑っているディメンション
• 正確な description frontmatter
• 関連する SKILL.md の該当箇所
• 発火してほしいプロンプト例と、発火してほしくないプロンプト例
• 自分たちの合格基準

こうした情報があると、特にディメンション別の診断において、この方法論が意図する形に近い推論をさせやすくなります。

発火する例と発火しない例を両方出す

改善効果が大きい入力のひとつが、次の両方をそろえて渡すことです。

• スキルが発火すべきプロンプト
• スキルが黙っているべきプロンプト

これはルーティング品質の分析に直結します。単に「関連ありそうか」を問うのではなく、precision と recall の両方を見るという、この方法論の考え方にも合っています。

static の修正と judge レイヤーの修正を分ける

すべての改善が同じ種類とは限りません。問題を次のように分類してもらうと有効です。

• structural fixes: frontmatter、欠けている契約、弱い progressive disclosure
• rubric fixes: 説明不足、ガイダンスの曖昧さ、実行可能性の弱さ
• behavior-fit fixes: 現実的なプロンプトの揺れに対して起こりそうな triggering ミスマッチ

こうしておくと、違う箇所を過剰に直してしまうのを防げます。

もっとも多い失敗パターンを避ける

よくある失敗は、見つけられやすさを上げようとしてスキルの範囲を広げすぎることです。見かけ上のカバレッジは上がっても、triggering precision を落とすことがあります。説明文を改訂したあと、evaluation-methodology skill に「汎用化しすぎていないか」を確認させるのが有効です。

勘だけでなく rubric anchor で反復する

最初の出力を得たら、次のように聞いてみてください。

Which anchor in references/rubrics.md best matches this draft now, and what exact evidence keeps it from the next anchor?

この質問のほうが、単に「どう改善できますか」と聞くよりも、どの修正が実際のスコア変動につながるかを具体的に引き出しやすくなります。

最小変更での改善案を求める

素早く回したいなら、全面改稿ではなく最小修正を求めるのが効果的です。

Using the evaluation-methodology skill, recommend the three smallest wording or structure changes most likely to improve the composite score without changing scope.

意図やスコープを保ちながら、評価対象となるディメンションに絞って改善できるため、フルリライトより実用的なことが多いです。

改善が狙った指標に効いたかを再確認する

文書が読みやすくなっても、この方法論で見たときに改善していないことはあります。修正後は、次の点を比較するよう依頼してください。

• Triggering Accuracy への想定効果
• Orchestration Fitness への想定効果
• composite score への見込み影響
• 編集によって新たに生まれたトレードオフの可能性

evaluation-methodology guide が本当に効いてくるのはこの最終確認です。フレームワークを説明するだけでなく、その枠組みの中でどう改善するかまで支援してくれます。