eval-harness-first
Helps create a system to test AI models before training them. It ensures models meet quality criteria and compares them against others.
What it does
This tool builds a test suite to check if an AI model is performing well. It helps identify and fix errors before training the model.
When to use it
- ✓When starting to train an AI model.
- ✓When converting conversation examples into a test set.
- ✓When comparing a model's performance against human evaluations.
Example of what to ask your AI
“Create a test suite to evaluate our new chatbot model.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
It analyzes conversation examples to find common error types. Then, it creates specific tests for each error type and checks if the model improves after training.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add wshobson/agents --skill eval-harness-firstOr download just the file:
curl -L https://raw.githubusercontent.com/wshobson/agents/main/plugins/llm-finetuning/skills/eval-harness-first/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
Eval Harness First
The Phase 0 gate for the whole plugin:
finetuning-method-selection and every downstream
skill assume this harness exists before a training
config gets written. The harness is not a run-end
side artifact — it is the data-curation engine. The
same labeled traces that build the goldens feed
training data, minus an explicit holdout.
Input: production/agent traces if they exist, or
a task spec if they don't, plus labelers willing to
grade ≥100 examples.
Output format: the eval/ directory below —
goldens, graders, drift suite, and the base-model
baseline that later phases gate on.
The Gate
No eval harness, no fine-tune. Skip to a training config and there is nothing to measure against, nothing to catch regressions, and no labeled data to train on. The flywheel:
- Collect traces — production/agent spans, or synthetic tasks if none exist yet.
- Error analysis — open coding on ≥100 traces, axial coding into 4–8 failure buckets.
- One grader per bucket — deterministic first; calibrated LLM-judge only for genuinely subjective criteria.
- Prioritize by frequency × severity × value.
- The labeled traces feed dataset curation, minus
an explicit holdout. Every
eval/goldens.jsonlID stays excluded from training data by ID. - Train.
- Re-run the same harness on the checkpoint — not a different, looser one.
- Drift detection feeds back to step 2 — new production failure modes re-open error analysis.
Steps 2–4 build the harness; steps 5–8 are why it must exist first — it is both the training data source and the checkpoint's exit gate.
Building Goldens
- From traces, when they exist: run error analysis — open coding on ≥100 real traces (read them, tag failures in your own words, no fixed taxonomy yet), then axial coding to collapse those tags into 4–8 named failure buckets. Fewer than 4 means the coding pass was too shallow; more than 8 means buckets need merging. Exception: single-failure-surface tasks (e.g. strict-schema extraction) may land at 1–2 buckets with per-field sub-metrics inside one grader — don't invent artificial splits with no evidence behind them.
- Synthetic, when traces don't exist yet: dimension-based generation — enumerate the axes that matter (task type, difficulty, edge case, persona) and sample the cross-product; free- generated prompts cluster around whatever's easiest to write.
- Goldens are versioned like code — commit
eval/goldens.jsonl, diff it in review, tag it per release. It doubles as the CI regression suite.
Graders
One grader per failure bucket from error analysis — not one for the whole eval set. A single blended score hides which bucket regressed.
- Deterministic first. Regex, schema validation, or execution checks are cheaper, reproducible, and need no calibration.
- LLM-judge only for genuinely subjective criteria — tone, faithfulness, "which response is better" — where no deterministic check can express it.
- Binary pass/fail over Likert. A 1–5 or 1–10 scale is noisier to calibrate and harder to apply consistently; collapse to pass/fail.
- Drift-suite MMLU-style scoring: prefer logprob
over generate-and-extract — a tight token budget
makes generate-and-extract parse-brittle for models
that preamble, conflating format compliance with
the knowledge being measured. Templates for all
four grader shapes and this scoring note:
references/grader-templates.md.
Judge Calibration Is a Prerequisite
Any bucket routed to an LLM-judge needs calibration before its verdicts count for anything beyond exploration — a hard prerequisite, not a nice-to-have. N/A when no bucket routes to a judge — an all-deterministic harness has nothing to calibrate; state that rather than leaving this section unaddressed.
- Label ≥100 items, split train/dev/sealed test (report once, no re-touching after).
- Report TPR and TNR, not one blended accuracy number — a judge can hit 90% by always saying "pass" on a skewed set.
- Pin the judge to a fixed model snapshot and recalibrate on judge-model change, quarterly regardless.
- The judge must come from a different model family than the model under test.
- A judge that misses the agreed TPR/TNR bar ships advisory-only — flags for human review, never gates a promotion. Full protocol, bias correction,
…
FAQ
What are 'goldens'?
'Goldens' are perfect examples of how the model should respond, used as a reference for tests.
What are 'graders'?
'Graders' are automatic checkers that evaluate if the model's responses are correct in each error category.
Why is a 'baseline' important?
The 'baseline' is the model's initial score before any training. It serves as a comparison point to know if the training actually improved the model.
Details
Original description by the author
Build the evaluation harness that gates every fine-tuning run — golden sets, per-failure-mode graders, judge calibration, and base-model baselines. Use when starting a fine-tuning effort, when converting traces into an eval set, or when calibrating a judge against human labels.
repo: wshobson/agents
Popularity
- GitHub stars
- 41k
- Ranking position
- #4897
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
screen-reader-testing
Has your agent test websites using screen readers to ensure they are accessible.
wshobson/agents
wcag-audit-patterns
Helps your agent audit websites for accessibility and fix issues according to WCAG guidelines.
wshobson/agents
multi-reviewer-patterns
Enables your agent to coordinate parallel code reviews, deduplicating findings and consolidating reports.
wshobson/agents
parallel-debugging
Allows the agent to debug complex issues with parallel investigations and root cause analysis.
wshobson/agents
Similar skills
agent-architecture-audit
Makes your agent check if everything is working correctly. It finds and fixes problems in AI systems, ensuring they perform as expected.
affaan-m/ECC
agent-eval
Helps your agent compare different AI coding tools. It measures which one is faster, cheaper, and more reliable for specific tasks.
affaan-m/ECC
agent-harness-construction
Makes your agent better understand how to perform tasks. It optimizes the tools and instructions the agent uses to increase its chances of success.
affaan-m/ECC