agentleFS
OpenxIntelligenceOpenxIntelligence/Coding-Agent-Skills/agent-eval/SKILL.md

agent-eval

Skill4 starsChanged 25 days agoMITView on GitHub

Evaluate whether an agent's or loop's OUTPUT is actually good, the way Anthropic prescribes — grade final-state not trajectory, per-dimension isolated LLM-as-judge with an "Unknown" escape, pass^k reliability (not just pass@k), Cohen's-kappa judge calibration, and trajectory metrics kept as diagnostics. Use when measuring an agent/loop, building an eval suite or eval-as-CI gate, judging generated output quality, deciding if a prompt change helped, or calibrating an LLM judge. Backed by lib/agent_eval.py. Trigger phrases: eval, evaluate agent, llm as judge, pass^k, pass at k, grade output, eval harness, judge calibration, measure the loop, eval as CI.

34 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use backend-patterns and api-design.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • HABUBUSSSkill

    backend-patterns

    Backend architecture patterns, API design, database optimization, and server-side best practices for Node.js, Express, and Next.js API routes.

    Also in 3 projects that use this

  • MicrosoftSkill

    api-design

    Guide for designing and documenting RESTful APIs. Use when asked to design an API, create endpoints, or document an API.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 29 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Evals as CI + read the transcripts: Run on every commit; keep regression evals ~100%, rotate saturated capability evals in.

    line 30
  2. Very specific:

    Run as a claudelab probe (mirror probe_skill_realworld_hit's -1 sentinel until n≥sample) or as a pre-merge CI gate.

    line 60

“Common” is measured: kept by at least 6 in 10 of the 29 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Agent-Output Evaluation

"Build evals before you trust the loop." This skill packages Anthropic's eval discipline (Demystifying evals for AI agents; multi-agent research system) over the tested primitives in lib/agent_eval.py. The full prescription is in plans/anthropic-loop-harness-playbook.md §Evaluation.

The seven rules (each maps to a lib function or a practice)

  1. Grade the outcome / final state, not the trajectory. "Agents find alternative paths to the same goal." Your grade_fn checks the end state (reservation exists, tests pass, file count) — not the tool-call sequence. run_eval_suite keeps turns/tool-calls/tokens/cost in diagnostics, separate from pass/fail.
  2. Per-dimension isolated judge. Grade each rubric dimension with its own judge call, then aggregate_dimensions(verdicts) → one outcome (any FAIL → FAIL; all PASS → PASS).
  3. Give the judge an "Unknown" escape. Instruct the judge to return UNKNOWN when it lacks info, instead of hallucinating a verdict. aggregate_dimensions never lets UNKNOWN pass silently — it surfaces needs_human: true (or use unknown_is_fail=True for a strict gate).
  4. Report pass^k, not just pass@k. pass_at_k(n,c,k) = ≥1 of k succeeds (flatters); pass_hat_k(n,c,k) = ALL k succeed (the real reliability). They tell opposite stories at high k — gate production on pass_hat_k.
  5. Calibrate the judge against humans. cohen_kappa(judge_labels, human_labels) ≥ 0.6 before you trust an LLM judge; re-check when you change the rubric or the judge model.
  6. Start with 20–50 realistic tasks, run multiple trials each (non-determinism), and use balanced two-sided sets (cases where the behavior should AND shouldn't occur).
  7. Evals as CI + read the transcripts. Run on every commit; keep regression evals ~100%, rotate saturated capability evals in. Layer Swiss-Cheese (automated → monitoring → A/B → human). Actually read failing transcripts — tooling for that is non-optional.

Wire real judges to the lib

import agent_eval as ae

DIMENSIONS = ["correctness", "completeness", "no-regression"]   # rubric, one judge each

def grade_fn(task, run_result):
    # outcome grade: per-dimension isolated judges, each a SEPARATE Agent/claude -p call with a
    # rubric + the produced artifact, instructed to answer PASS / FAIL / UNKNOWN only.
    verdicts = [judge_one_dimension(dim, task, run_result) for dim in DIMENSIONS]  # your LLM calls
    return ae.aggregate_dimensions(verdicts)        # -> {status, needs_human, ...}

def run_fn(task):
    # the agent/loop under test; return the final artifact + trajectory diagnostics
    return {"result": ..., "turns": ..., "tokens": ..., "cost_usd": ...}

suite = ae.run_eval_suite(TASKS, run_fn, grade_fn, trials=5, k=5)
# gate on suite["mean_pass_hat_k"]; inspect suite["diagnostics"] for cost/turn trends

Judge construction: use a different model than the maker (Opus/Fable judging Haiku/Sonnet output), a fresh context, a skeptical rubric ("find why it fails; answer UNKNOWN if unsure"). For quick in-loop accept/reject use the evaluator-optimizer skill; for suite-level reliability use this.

Wire to this setup

  • Run as a claudelab probe (mirror probe_skill_realworld_hit's -1 sentinel until n≥sample) or as a pre-merge CI gate. Feed the suite's accept-rate into the CAPC ledger (probe_cost_per_accepted_change) so eval pass-rate and cost-per-accepted-change move together.
  • Companions: evaluator-optimizer (the in-loop checker), quality-gates (evidence discipline), loop-designer (the non-rotting-gate checklist this operationalizes).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.