From loopkit
Calibrates LLM evaluator agents with few-shot rubric examples to prevent score drift over long runs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/loopkit:evaluator-calibrationWhen to use
standing up an evaluator/critic agent for a multi-agent harness, noticing evaluator scores drift upward across many iterations, grading skill/PR/diff output with an LLM and wanting reproducible verdicts
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
An evaluator agent that reads the generator's reasoning drifts lenient. The generator explains why the code is good; the evaluator, priming on that prose, starts nodding along. By sprint 8 the "skeptical critic" is a rubber stamp. Prithvi flagged this in the March 2026 planner/generator/evaluator writeup — evaluator leniency is the failure mode of the three-agent harness.
An evaluator agent that reads the generator's reasoning drifts lenient. The generator explains why the code is good; the evaluator, priming on that prose, starts nodding along. By sprint 8 the "skeptical critic" is a rubber stamp. Prithvi flagged this in the March 2026 planner/generator/evaluator writeup — evaluator leniency is the failure mode of the three-agent harness.
The fix is not "tell the evaluator to be stricter." That works for one iteration. The fix is anchoring the rubric with concrete pass/fail examples the evaluator re-reads every invocation, and re-prompting from scratch on a fixed cadence so drift can't accumulate.
Write the rubric as a scored checklist, not prose. Each criterion gets a name, a one-line definition, and a binary or 1-3 score. Prose rubrics ("evaluate whether the code is well-designed") drift; checklists don't.
Anchor every criterion with 2 concrete examples — one pass, one fail. Real examples from prior runs, not invented ones. The evaluator reads these every invocation. This is the calibration; without it you're just prompting hope.
Forbid reading the generator's reasoning before scoring. The evaluator sees the artifact (code, diff, output) and the rubric. It does not see the generator's "here's why this is good" prose. Score first, then optionally read the reasoning to write the critique.
Require the evaluator to quote the artifact in every verdict. "Fails criterion 3 because " — not "fails criterion 3." Quoting forces grounding and makes the verdict auditable.
Re-prompt from scratch every N iterations. Empirically N=5 works. Kill the evaluator's context, reload the system prompt + rubric + examples fresh. Do not compact; compaction preserves the drift.
Log verdict distributions. Track pass rate per criterion per sprint. A criterion that goes from 40% pass to 90% pass without a spec change is drift, not improvement.
Spot-check with a held-out fail. Every ~10 sprints, feed the evaluator an artifact from your example set that you know fails. If it passes, the calibration has decayed — regenerate the example set from recent real runs.
Single-shot grading with a fresh context every call — there's no drift to prevent, and the examples are overhead. Also skip for tasks under ~1 hour where the evaluator only runs 2-3 times.
npx claudepluginhub archive228/loopkit --plugin loopkitAnswers AI agent evaluation methodology questions using Microsoft's agent evaluation ecosystem, covering grader types, dataset design, criteria writing, non-determinism, tool-call evaluation, and multi-turn agents.
Builds evaluation systems for agent pipelines: deterministic checks, regression suites, multi-dimensional rubrics, quality gates, and production monitoring.
Use this skill when the user asks to "set up LLM as a judge", "write an LLM judge prompt", "automate quality evaluation", "use Claude to evaluate outputs", "build an automated eval", "LLM-based evaluation", or wants to create a scalable automated evaluation system where one LLM grades the outputs of another LLM.