AI Eval Plan Skill

You can't improve an AI feature you can't measure, and "it looks good in the demo" is not measurement. This skill produces an evaluation plan that turns a fuzzy quality goal into a repeatable, gated test — so a prompt change that quietly makes outputs worse can't ship.

Required Inputs

Ask for these only if they aren't already provided:

• The feature & task — what the model does and what "good output" means to a user.
• Failure modes that matter — what bad looks like (hallucination, wrong format, unsafe, off-tone, too slow).
• Available data — any real examples, logs, or labelled cases; or note there are none yet.
• Who judges quality — automated checks, an LLM judge, human raters, or a mix.
• The decision this gates — ship/no-ship, model selection, or prompt iteration.

Output Format

Eval Plan: feature]

1. What we're measuring — the task, and a one-line definition of a good vs. bad response.

2. Eval dataset

• Cases: how many, where they come from (real logs > synthetic), and how they're split (smoke set vs. full set).
• Coverage: the slices/scenarios that must be represented (edge cases, adversarial, each major input type).
• Golden answers / references: present or not, and how they were created.

3. Metrics & rubric

• Per-dimension scores — define each dimension (e.g. correctness, grounding, format, safety, tone) on an explicit 1–5 rubric with anchor descriptions, not vibes.
• Automated checks — deterministic assertions first (valid JSON, contains required fields, no PII, latency budget).
• LLM-as-judge — the judge prompt, the rubric it applies, and how you guard against its bias (calibrate against human labels on a sample).
• Human eval — when it's required (safety, subjective quality) and the rater instructions.

4. Baselines — what each candidate is compared against (current prompt, previous model, a plain-prompt control).

5. The bar — the explicit threshold to ship (e.g. "≥4.2 avg correctness, 0 safety failures, p95 < 3s") and what happens if it's missed.

6. Regression gate — how this runs in CI on every change, and the score-drop threshold that blocks a merge.

Quality Checks

• ] Each metric has an explicit rubric with anchors — not just a name
• ] Deterministic/automated checks are used wherever possible before reaching for an LLM judge
• ] The LLM judge is calibrated against human labels on at least a sample
• ] The eval set includes adversarial and edge cases, not just happy-path examples
• ] There is a single, explicit numeric bar for the ship decision
• ] The plan specifies how it runs as a regression gate, not just a one-time check

Anti-Patterns

• ] Do not rely on a single overall score — a feature can pass on average while failing every safety case
• ] Do not trust an LLM judge you haven't calibrated against humans — it has its own blind spots and biases
• ] Do not eval only on happy-path inputs — the failures live in the edges and the adversarial cases
• ] Do not let the eval set leak into the prompt/few-shot examples — that's training on the test set
• ] Do not define the pass bar after seeing the scores — set the threshold before you run, or it means nothing

Based On

LLM evaluation practice — task-grounded rubrics, LLM-as-judge with human calibration, and regression-gated CI evals.