Development

Evals

Assertion-first AI eval framework aligned to Anthropic's 'Demystifying evals for AI agents' — typed deterministic asserts + a forced-structured LLM judge over an input→assert case schema, pass^k/pass@k, capability vs regression suites, subscription-billed

08
Workflows
12
Tools
04
References
13
Triggers

The Problem

When an AI agent breaks, you usually find out after the fact — wrong tool call, bad output, regression from a prompt change you thought was safe. Generic testing frameworks grade final outputs but miss everything that happened in between: which tools were called, in what order, whether the agent took a reasonable path to get there. You also have no principled way to distinguish a capability gap (the agent can't do this yet) from a regression (the agent used to do this and now doesn't). Without that distinction, you're flying blind when upgrading models or iterating on prompts.

How This Skill Approaches It

Evals evaluates agent workflows — transcripts, tool-call sequences, multi-turn conversations — not just outputs. Three grader types cover different verification needs: code-based graders (string_match, regex_match, binary_tests, tool_calls, state_check) run fast and deterministically; model-based graders (llm_rubric, natural_language_assert, pairwise_comparison) handle quality and nuance; human graders calibrate the LLM judges against gold standard. pass@k scoring runs multiple trials to get statistical significance, and pass^k measures consistency. Capability evals target ~70% pass rate as a stretch goal; regression evals target ~99% as a quality gate. TrialRunner.ts handles multi-trial execution, SuiteManager.ts manages eval suites and saturation checks, FailureToTask.ts converts real failures into test cases, and AlgorithmBridge.ts wires eval results directly into Algorithm ISC rows for automated verification. Pre-configured domain patterns (coding, conversational, research, computer-use) give you a grader stack to start from.

Not for scientific-method framing (use Science), property/mutation testing of code (use Hardening), or live UI verification (use Interceptor)

In Action

What you say to your DA, and what the Evals skill actually does.

  • You say "run evals on the auth skill after the changes i made"
    Runs RunEval against the existing auth test suite via AlgorithmBridge.ts, executes pass@3 trials, grades with the domain's pre-configured grader stack (binary_tests + tool_calls + llm_rubric), and reports pass rate, any regressions, and updated ISC row status.
  • You say "compare these two prompt versions and tell me which produces better summaries"
    Runs ComparePrompts: creates a grading suite with pairwise_comparison and llm_rubric graders, runs both prompts against the same test cases with position swapping, and reports pass@k scores plus a comparative analysis of where each prompt wins and loses.
  • You say "create a regression test from that auth bypass failure we just fixed"
    Runs CreateUseCase: logs the failure via FailureToTask.ts, defines an unambiguous task with code-based and model-based graders, and adds it to the regression suite so the same failure can never silently reappear.

Inside the Skill

The thinking, frameworks, and architecture that distinguish this skill from a generic version of the same task.

What it is

An eval gives an AI an input, then applies assertions to its output to measure success (Anthropic's definition). A case is {id, prompt, assert:[...]}. Each assertion is either deterministic (code, fast/free) or model-graded (an LLM judge). Cases run multiple trials; we report pass^k (all trials pass — the honest metric for a reliability-critical agent) and pass@k (any trial passes). Everything routes through Inference.ts — subscription-billed, no API-key path, no external deps.

Grounded in Anthropic's current doctrine — Demystifying evals for AI agents, Define success criteria / develop tests, and the skill-creator {text, passed, evidence} assertion convention. The typed-assert layer is promptfoo-shaped but our own TS.

Freshness contract: "aligned to Anthropic's doctrine" is a live claim, not a snapshot. When designing a new suite class or touching the ## Doctrine section below, re-fetch the Demystifying-evals doc and flag where it has moved past what's encoded here. Advisory only — report divergence, never auto-adopt, and an unreachable URL never blocks a run.

The canonical path (v2)

Tool Role
Tools/Assertions.ts Deterministic assert engine: equals, contains, icontains, contains-all/any, regex, starts-with, ends-with, is-json, contains-json, max-length, min-length, each with not- negation. Sync, no model call.
Tools/Judge.ts Model-graded asserts llm-rubric (1–5 → 0–1, threshold) and llm-assert (NL assertions → TRUE/FALSE/UNKNOWN). Forced-structured JSON verdict, reason-then-score, distinct judge level, Unknown→miss escape hatch.
Tools/EvalRunner.ts Loads a suite, runs the agent-under-test per case (single-shot inference against the target system prompt), applies asserts, computes pass^k/pass@k, persists transcripts + latest.json.
Tools/SuiteManager.ts Suite listing + saturation tracking.
Tools/FailureToTask.ts Convert real failures into cases (seed from 20–50 real failures).
# Run a suite (USER-customization suites resolve before the skill's own)
bun run ${LIFEOS_SKILL_DIR}/Tools/EvalRunner.ts -s <suite> [-t trials] [--json]
# Sanity-check the assert engine / judge
bun run ${LIFEOS_SKILL_DIR}/Tools/Assertions.ts # 16-case self-test
bun run ${LIFEOS_SKILL_DIR}/Tools/Judge.ts # good-vs-bad discrimination

Suite / case schema (assertion-first)

name: my-suite
type: regression # or capability
pass_threshold: 0.75
agent_level: medium # agent-under-test inference level
judge_level: high # judge!= generator (Anthropic best practice)
trials: 3
# system_prompt: optional override; default = live system prompt + DA identity
cases:
 - id: descriptive_name
 prompt: "the user turn sent to the agent-under-test"
 assert:
 - type: not-contains # deterministic
 value: "should work"
 weight: 1
 - type: llm-rubric # model-graded, weighted for partial credit
 weight: 2
 value: "Does the output tie any done-claim to verification evidence?"
 - type: llm-assert
 weight: 1
 value: ["The output does not claim success without evidence"]
 - id: should_not_case # balance: test should-do AND should-not
 negative: true
 prompt: "..."
 assert: [...]

Identity-bound suites (e.g. {{DA_NAME}}'s dispositions) live in LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Evals/Suites/ — the public skill ships only generic suites/examples.

Doctrine (from Anthropic — encode, don't restate)

  • Grade the output/outcome, not the path. Tool-call-sequence asserts are brittle and demoted to opt-in; the everyday suite grades what the agent produced. The legacy core-behaviors suite (tool-sequence graded) is retained only as an example of this anti-pattern — it is a v1 tasks: file and is not runnable by EvalRunner, which reports it as a named error rather than attempting it.
  • Capability starts low (a hill to climb); regression targets ~100%; passing capability cases graduate into regression.
  • pass^k for reliability, pass@k where one success suffices.
  • Partial credit via assert weights. Balance should-do and should-not cases — one-sided evals create one-sided optimization.
  • Judge discipline: distinct judge model, reason-then-score, forced structured verdict, an Unknown escape hatch.
  • Never trust a score until you read transcripts — every run persists full case transcripts to MEMORY/STATE/Evals-Results/<suite>/<run>/run.json.

Harness integration

  • Config-change regression: hooks/ConfigEvalFire.hook.tsLIFEOS/TOOLS/ConfigEvalOnChange.ts fires the configured dispositions suite when a behaviour-defining file changes (default core-dispositions, the runnable v2 suite; override via LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Evals/config.json config_change_suite — identity-bound suites live in that USER layer, never the public tree); regressions notify Pulse. Non-blocking, subscription-billed, debounced.
  • ISA / Algorithm: an eval suite is the operational form of an ISA claim's falsifier (integration map kept on the maintainer machine — session notes, does not ship).

Legacy (v1, superseded)

The v1 grader-stack (Graders/, TrialRunner.ts) and the @langwatch/scenario path (ScenarioRunner.ts, LifeosAgentAdapter.ts, API-billed) predate the assertion-first rewrite. Prefer the v2 path above. The scenario path bills ANTHROPIC_API_KEY — do not use it for principal work.

Gotchas

  • Single-shot agent-under-test narrates tool calls. Running the full agentic system prompt through tool-less inference makes the agent defer and simulate tool use instead of answering — which tanks "lead with the answer" style cases. EvalRunner injects an [EVALUATION CONTEXT] no tools, answer directly suffix to fix this; keep it when authoring output-graded disposition cases.
  • judge_level must differ from agent_level (Anthropic: judge ≠ generator). Default agent=medium, judge=high.
  • Unknown counts as a miss. A judge that can't verify an assertion returns UNKNOWN, scored as fail — conservative for regression, correct for gates.
  • Deterministic asserts are free; use them first. Reserve model asserts (llm-rubric/llm-assert) for nuance a code check can't capture.
  • is-json checks the whole output; contains-json checks for an embedded fragment. Don't use is-json on prose that merely mentions JSON.

Workflows & Routing · 8

Each workflow is one job the skill runs. The trigger phrases route your request to the right one — this is the skill's routing table.

  1. 01
    RunEval Workflows/RunEval.md

    run the eval, run suite, evaluate this, grade output

  2. 02
    CreateUseCase Workflows/CreateUseCase.md

    new eval, create a suite, eval for X, what should I test

  3. 03
    CreateJudge Workflows/CreateJudge.md

    write a judge, llm-rubric, grading criteria, judge prompt

  4. 04
    ComparePrompts Workflows/ComparePrompts.md

    compare prompts, which prompt is better, A/B this prompt

  5. 05
    CompareModels Workflows/CompareModels.md

    compare models, which model is better, is the cheaper rung enough

  6. 06
    ViewResults Workflows/ViewResults.md

    eval results, how did it score, show the last run, saturation

  7. 07
    CreateScenario Workflows/CreateScenario.md

    create a scenario, multi-turn eval, scenario test

  8. 08
    RunScenario Workflows/RunScenario.md

    run the scenario, run multi-turn

Tools · 12

Deterministic executables the workflows call — the code that does the real work, not prompt scaffolding.

  • Assertions.ts
  • EvalRunner.ts
  • FailureToTask.ts
  • GenerateCases.ts
  • Judge.ts
  • LifeosAgentAdapter.ts
  • ProposeFromFailures.ts
  • ScenarioRunner.ts
  • ScenarioToTranscript.ts
  • SuiteManager.ts
  • TranscriptCapture.ts
  • TrialRunner.ts

How to Invoke

Say any of these to your DA and LifeOS activates the Evals skill automatically:

  • "eval"
  • "evaluate"
  • "benchmark"
  • "regression test"
  • "assertion"
  • "assert"
  • "llm-rubric"
  • "judge"
  • "pass@k"
  • "pass^k"
  • "grade output"
  • "compare prompts/models"
  • "test agent"

Or invoke explicitly:

Skill("Evals")

References · 4

Auxiliary files the skill loads at runtime — frameworks, guides, configs.

  • BestPractices
  • ScienceMapping
  • ScorerTypes
  • TemplateIntegration

References & Credits

The thinkers, books, frameworks, and research this skill is built on. The ideas belong to them — the integration belongs to LifeOS.

Want LifeOS to do this for you?

Install LifeOS on your machine — your DA gets the Evals skill plus 55 others, all hooked into one Life OS.