eval-grader

# Eval Grader <!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions truncated or dropped, which strips the very keywords a match depends on. --> Trigger phrases: "eval", "grader", "measure output quality", "LLM-as-judge", "score the output" **Measure every change; don't vibe it.** When you iterate on a prompt, an agent, or any generative output (docs, slides, UI, a summary, an extraction), a two-layer grader over a fixed task set turns "feels better" into a signed number you can trust. This is the **external, machine-grounded verifier** the `iterate` skill asks for — a model grading its *own* output inflates; a separate grader on a fixed suite does not. > **Kit adaptation (local, .claude/):** use when tuning a generative task; the scorecard goes to `docs/EVAL.md` > (§4.3). Stack-agnostic — graders are ordinary code + judge calls. §4 Prohibitions apply. ## Two layers - **Layer 1 — code graders** (deterministic, near-free, run every time): structural metrics over the artifact — *did it produce a valid result?* plus counts, sizes, schema validity, "wall-of-text" / clutter flags. They catch gross regressions a judge shouldn't be spent on. Ground truth is **computed from the source**, not hand-authored. - **Layer 2 — LLM-as-judge graders** (semantic): **one call per dimension** (clarity · correctness-vs-source · completeness…...