Install any skill in seconds. Free to start, no credit card required.
Get Started Free →archive228/evaluator-calibration
Calibrate a reviewer persona with few-shot rubric examples so skepticism stays consistent and doesn't drift lenient over long runs.
Passed 17 of 22 test cases with the skill, and 8 of 22 without it.
and 10 more in the full report
10 fixed8 passed either way5 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
During sprint 12, our held-out test patch (which contains a known security flaw) was awarded a pass by our PR evaluator agent. What action should the engineering team take immediately?
| Checked | Without skill | With skill |
|---|---|---|
| Requires regenerating calibration examples from recent real runs | Missed | Passed |
The instructions your model reads when the skill loads.
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.
test cases passed, vs 8 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.