Menu
Guides systematic analysis of eval failures using traces. Use when a suite is failing, model outputs seem inconsistent, evaluator behavior is suspect, or you need to classify failures before changing prompts, metrics, or datasets.
Guides design of LLM-as-judge prompts for subjective evaluation criteria. Use when deterministic checks are insufficient and you need a judge prompt for quality dimensions like helpfulness, faithfulness, clarity, or tone.
Guides building or improving interfaces for human review of eval traces. Use when humans need to inspect failures, label outputs, compare model behavior, or audit evaluator decisions at scale.
Guides evaluation of RAG pipeline retrieval and generation quality. Use when evaluating a retrieval-augmented generation system, measuring retrieval quality, assessing generation faithfulness or relevance, generating synthetic QA pairs for retrieval testing, or optimizing chunking strategies.
Guides creation of synthetic eval cases that expand coverage without drifting away from real usage. Use when the current eval set is too small, too repetitive, or missing edge cases, and you need more diverse prompts, distractors, or structured scenarios.
Drafts a reviewable judge-template patch from evaluator validation disagreements.
Guides validation of evaluators, especially LLM judges, against labeled examples. Use when evaluator quality is uncertain, judge scores seem inconsistent, or you need to check whether the evaluator is biased, noisy, or misaligned.
| name | error-analysis |
| description | Guides systematic analysis of eval failures using traces. Use when a suite is failing, model outputs seem inconsistent, evaluator behavior is suspect, or you need to classify failures before changing prompts, metrics, or datasets. |
Run the relevant eval suite and collect traces. Inspect traces/, run-eval.mjs, tracer.mjs, and evaluators/index.mjs before proposing changes. If traces do not exist yet, run the smallest relevant suite first.
Run:
npm run skill:error-analysis
If labels exist under labels/, the script includes pivots by failure_mode, feature, scenario, persona, and suite. Use those pivots to prioritize fixes before changing prompts or eval metrics.
For the failing suite, inspect:
Do not infer a failure category without reading the actual trace.
Use categories such as:
If a failure does not fit an existing bucket, add a new one rather than forcing it into the wrong class.
Count how many failures land in each category. A good fix targets the dominant class instead of optimizing for one memorable example.
Examples:
traces/tracer.mjsrun-eval.mjsevaluators/index.mjsevals/app.htmllabels/docs/schemas/labels.md