Agent — does the agent deliver?
Brief 34

Eval Coverage Audit

The test-gap audit for nondeterminism — golden sets, regression evals, judge quality, and the drift between eval and production.

EVALS.md4 phases8 lenses~2.6k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: map what agent behavior is actually evaluated against what the product actually does, and produce the eval plan that catches regressions before users do.

Read-only pass. Your only write is the report file.

What it looks for

8 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Coverage vs reality

task types × eval existence: the matrix, with the uncovered high-volume cells circled

2

Golden-set health

size, age, whether cases came from real traffic or imagination

3

Judge quality

LLM judges never validated against human labels; position, length, and self-preference bias unchecked

4

Regression protection

prompt and model changes in git log that shipped with no eval run attached

5

Eval–prod drift

sanitized eval inputs vs the messy inputs production actually receives

6

Metric honesty

pass rates hiding severity; no cost or latency tracked alongside quality

7

Nondeterminism handling

single-sample pass/fail on stochastic outputs; no repeat runs, no variance reported

8

Failure feedback

production failures becoming new eval cases, or evaporating

The deliverable

What lands in your repo

One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.

EVALS.md
1
Coverage matrix
task type · volume · eval today · gap
2
Health verdicts
golden sets, judges, CI wiring
3
Eval plan
each: capability · dataset source (mine the traces) · grader (assertion/judge/human) · size · run trigger
4
The first eval
spelled out completely, buildable today
One file. Evidence-backed. It ends by asking before touching anything.
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Learn the eval reality

What exists.

2
Phase 2

Audit through 8 lenses

Coverage vs reality — task types × eval existence.

3
Phase 3

Curate

Rank gaps by volume × blast radius of an unnoticed regression.

4
Phase 4

Report

Create EVALS.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:eval-coverage-audit.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-eval-coverage-audit:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=34 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/34.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,634 characters)
# Goal: Eval Coverage Audit

You are working inside this repo. Mission: map what agent behavior is actually evaluated against what the product actually does, and produce the eval plan that catches regressions before users do.

Read-only pass. Your only write is the report file.

## Phase 1 — Learn the eval reality
- What exists: golden datasets, assertion suites, LLM judges, human review, dashboards? Where do they live, when do they run — CI, ad hoc, never?
- List the product's real task types (from code and traces), with rough volume per type.
- What raw material exists for building evals — traces, logs, user corrections?

## Phase 2 — Audit through 8 lenses
1. **Coverage vs reality** — task types × eval existence: the matrix, with the uncovered high-volume cells circled
2. **Golden-set health** — size, age, whether cases came from real traffic or imagination
3. **Judge quality** — LLM judges never validated against human labels; position, length, and self-preference bias unchecked
4. **Regression protection** — prompt and model changes in git log that shipped with no eval run attached
5. **Eval–prod drift** — sanitized eval inputs vs the messy inputs production actually receives
6. **Metric honesty** — pass rates hiding severity; no cost or latency tracked alongside quality
7. **Nondeterminism handling** — single-sample pass/fail on stochastic outputs; no repeat runs, no variance reported
8. **Failure feedback** — production failures becoming new eval cases, or evaporating

## Phase 3 — Curate
- Rank gaps by volume × blast radius of an unnoticed regression
- Prefer small, real-traffic golden sets over large synthetic ones

## Phase 4 — Report
Create `EVALS.md` at repo root:
1. **Coverage matrix** — task type · volume · eval today · gap
2. **Health verdicts** — golden sets, judges, CI wiring
3. **Eval plan** — each: capability · dataset source (mine the traces) · grader (assertion/judge/human) · size · run trigger
4. **The first eval** — spelled out completely, buildable today

Start the report with today's date. If `EVALS.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- An eval that never blocks a ship is a dashboard, not a gate
- Judge the judges: no LLM grader without a human-agreement check
- No LLM behavior to evaluate in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words
- Report only — end by asking which evals to build

House rules for this Goal Prompt

  • An eval that never blocks a ship is a dashboard, not a gate
  • Judge the judges: no LLM grader without a human-agreement check
  • No LLM behavior to evaluate in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
  • If a reports/ directory exists at the repo root, write the report there instead of the root.
  • Before asking, present the top findings as a ranked list in plain words
  • Report only — end by asking which evals to build
Keep exploring

Pairs well with

Curated neighbors — briefs that answer the adjacent question, worth running in the same session.

More Agent briefs

Runs inside these playbooks — curated sequences you can launch with one paste: