judge

judge の概要

judge の役割

judge スキルは、2段階の評価ワークフローを起動します。まず meta-judge がタスクに合った評価基準を定義し、その後、judge の sub-agent が切り離されたコンテキストと証拠に基づいて成果物を採点します。コード、分析、文章、agent の出力を、気軽な感想ではなく、規律あるレビューとして確認したいユーザーに最適です。

judge を使うべき人

明確な基準、引用、実行可能なフィードバックを備えたレポート形式の評価が欲しいときに judge スキルを使ってください。Skill Authoring のレビュー、repo の変更レビュー、そして確認バイアスやセッションの持ち越しが判断を歪めるおそれがあるあらゆるタスクに適しています。

何が違うのか

「feedback」を求める一般的な prompt と違い、judge は採点前に評価基準を組み立てます。そのため、成果物の種類がまだ不明なとき、多面的なスコアリングが必要なとき、あるいは別の人に対しても説明可能なレビューが求められるときに、judge スキルはより有効です。

judge スキルの使い方

judge をインストールしてエントリーファイルを確認する

npx skills add NeoLabHQ/context-engineering-kit --skill judge でインストールします。まずは plugins/sadd/skills/judge/SKILL.md を確認してください。ここに、judge のインストール時の振る舞いを定義するワークフロー、入力、評価制約がまとまっています。

judge に具体的な評価対象を与える

このスキルは、何を評価するのかと、どの観点で見るのかを明示したときに最も力を発揮します。たとえば、よい prompt は Judge the last draft of the launch page for clarity, SEO fit, and factual accuracy. のようになります。Review this のような弱い指示だと、meta-judge が推測しなければならない範囲が広すぎます。

judge のパイプラインに必要なコンテキストを渡す

評価対象の成果物、達成条件、そして tone、audience、rubric の優先順位、禁止変更などの厳しい制約を含めてください。Skill Authoring に judge を使うなら、そのことを明示し、対象の skill 名も挙げてください。インストールのわかりやすさ、見つけやすさ、手順の質で rubic を変えるべきだからです。

まず読むべきファイル

インストールと適用のためには、まず SKILL.md を読み、その後で repo に含まれる workflow や policy ファイルを確認してください。この repository では skill 本体が主たる信頼源です。つまり、最短ルートは、あなたのシステムに同じパターンを移す前に、prompt の構造、workflow の各 phase、証拠要件を先に把握することです。

judge スキル FAQ

judge は code review 専用ですか？

いいえ。judge スキルは、rubric で評価すると有益なあらゆる成果物、つまり prompt、docs、分析、agent の出力、設計判断などを評価するためのものです。重要なのは、明示的な基準と証拠に照らして結果を判定できることです。

どんなときに judge を使うべきではありませんか？

単に素早い主観的な反応が欲しいだけのとき、まだ完成した成果物がないとき、あるいは証拠から評価できないタスクのときは、judge を使わないでください。その場合は、もっと単純な prompt のほうが通常は速く、壊れにくいです。

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

はい。成果物と成功条件を言語化できるなら向いています。初心者がつまずきやすいのは、文脈なしに判断だけを求めたときです。このスキルは meta-judge の段階を強制することでその問題を減らしますが、それでも明確な対象は必要です。

judge は通常の prompt とどう違いますか？

通常の prompt では、1つの model に基準の発明と結果の採点を同時にやらせがちです。judge スキルはその役割を分けるため、整合性が上がり、バイアスが減り、最終レポートも信頼しやすくなります。

judge スキルを改善する方法

評価対象を明確にする

judge に最適な入力は、正確な成果物名、想定読者、そして支援したい意思決定を明示しています。たとえば、Evaluate the new onboarding doc for first-time contributors, with emphasis on setup clarity and missing prerequisites. のように書くと、Check my doc より優れています。後者では、rubric を実際のユーザーリスクに合わせにくいからです。

rubric に影響する制約を追加する

行単位の証拠、引用必須条件、特定の採点スケールを重視したいなら、最初に伝えてください。judge は、正確さ、網羅性、UX のわかりやすさ、ポリシー順守のどれを優先すべきかを知っているほうが、暗黙に平均化するよりもよい結果を出します。

最初のレポートの後に反復する

最初の judge レポートを使って、次の prompt を絞り込みます。足りないコンテキストを追加し、トレードオフを明確にし、採点が甘かったと感じた section を特定してください。Skill Authoring では、インストールのわかりやすさ、使用時の現実感、境界ケースを分けて再評価させるのが、最も役立つ反復になることが多いです。

よくある失敗モードに注意する

元の成果物が曖昧なとき、成果物が未完成なとき、評価の焦点に目標を詰め込みすぎたときは、judge の性能が落ちることがあります。その場合は、タスクをより狭い段階に分け、その時点の意思決定に必要な材料だけを judge に渡してください。