agentleFS
nicholas-greenwoodnicholas-greenwood/agentic-engineering-skills/llm-evaluation/SKILL.md

llm-evaluation

Skill3 starsChanged 16 days agoMITView on GitHub

use when evaluating LLMs, prompts or workflows

19 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use code-review.

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.
  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 17 edited versions we read keep these.

  • 2

    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. Very specific:

    commit and input/prompt/rubric hashes.

    line 23
  2. Distinctive:

    when using model judges, blind arm identities and balance answer order.

    line 35
  3. Distinctive:

    keep failures and missing results visible in the planned denominator.

    line 40

“Common” is measured: kept by at least 6 in 10 of the 17 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

evaluate the production workflow with frozen inputs and saved evidence

use paired arms for comparisons; for a single configuration, apply this workflow against frozen references, omitting comparator and pairing requirements

choose the runner

search the repository for maintained evaluation runners and current workflow guidance before building another harness; treat archived evaluations as historical evidence

inspect the matching runner's executable entry point, fixtures and scoring, and read any associated protocol before invoking it. reuse or adapt it when it fits; old budgets and release gates do not authorise a new run

freeze before running

save a short manifest and its artifacts in the task's evidence directory:

  • question, evaluated configuration(s), baseline/candidate comparison when applicable, scoring rubric, analysis method, uncertainty handling and decision rule/threshold when applicable
  • exact case ids, provenance, references/labels, target cohort, selection criteria/method and repetitions; label captured, synthetic and reconstructed inputs distinctly
  • original messages (including judge prompts) with roles, personas and formatting intact, plus tool descriptions, response schemas and source snapshots; save intentional prompt changes separately
  • commit and input/prompt/rubric hashes; include the evaluated patch for a dirty checkout
  • model/provider, reasoning, sampling/token limits, tool/search settings, caching and retries per arm and judge; record effective settings where available and mark unknowns
  • total budget for every arm, retries and judging, within current authorisation

done when each arm can be reconstructed from saved evidence without guessing or fetching mutable inputs

run and score

  • give each arm the same frozen cases and starting context; vary only the factor being evaluated and record unavoidable differences
  • preserve repetitions and balance arm order where relevant to expose baseline variability and time effects
  • retain requests, responses, tool traces, errors, usage, cost and latency keyed by (case id, arm, repetition)
  • score against the frozen rubric and saved sources/labels; model agreement alone is not factual correctness
  • when using model judges, blind arm identities and balance answer order; audit disputed decisions against sources or human labels

reconcile and report

  • report selected, attempted, returned and scored counts per arm, expected/observed (case id, arm, repetition) rows, and duplicate, missing, failed or empty rows
  • keep failures and missing results visible in the planned denominator; state quality denominators separately rather than silently dropping rows
  • compare aligned cases under the same rubric/settings except the evaluated factor; label exploratory subsets separately. incomplete coverage cannot establish a full-cohort win or pass its release gate
  • aggregate repetitions within each case before estimating uncertainty, using paired case differences for comparisons; retain per-case/group regressions and hard failures
  • link the manifest, raw evidence and scored outcomes; report paired differences, uncertainty/limitations, baseline variability and cost/latency with actual denominators
  • separate observed results from inference and mark incomplete or inconclusive decisions explicitly

done when every conclusion traces to saved case ids, settings and scoring evidence, and follows any frozen decision rule

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.