Skip to content
Skillpedia
Agents48k · #2043

agent-evaluation

Allows testing your agent's behavior. It's good for comparing changes, finding errors, and ensuring the agent keeps working correctly.

What it does

This tool helps test and compare different versions of an AI agent. It checks if the agent behaves as expected in specific situations, ensuring that changes made to it don't cause problems.

When to use it

  • ✓When testing a new version of an AI agent.
  • ✓To check if a past error still occurs.
  • ✓To ensure the agent continues to work well after updates.

Example of what to ask your AI

“Test agent X with test cases Y and compare the results with the previous version.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/sickn33/agentic-awesome-skills/blob/main/plugins/agentic-awesome-skills-claude/skills/agent-evaluation/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/sickn33/agentic-awesome-skills/blob/main/plugins/agentic-awesome-skills-claude/skills/agent-evaluation/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

You provide a set of tests with expected outcomes. The tool runs the agent with these tests and compares the actual behavior to the expected one, reporting any differences.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add sickn33/agentic-awesome-skills --skill agent-evaluation

Or download just the file:

curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/plugins/agentic-awesome-skills-claude/skills/agent-evaluation/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

Agent Evaluation

Evaluate observable agent behavior against task-specific cases. Modified by AAS maintainers on 2026-09-05 to remove unsupported benchmark claims, correct uncertainty/error reporting and separate optional architecture sketches from the operating procedure.

When to Use

Use when comparing a changed agent, prompt or tool configuration, reproducing an observed failure, or estimating reliability on a declared task distribution. Do not infer product readiness from a public benchmark percentage or a generic score threshold.

Prerequisites

  • A versioned case set with expected observable outcomes and permission boundaries.
  • A known baseline and candidate revision, including model, prompt, tools, configuration and runtime versions.
  • Authorized synthetic or redacted inputs, isolated targets and a bounded token, time and cost budget.
  • A verifier that distinguishes wrong outcomes, expected safe rejections, evaluator failures and infrastructure outages. Provider access is needed only if the declared evaluation calls that provider.

Evaluation procedure

  1. Freeze the contract. Record case IDs and dataset revision, baseline/candidate identities, target environment, repeat plan, budgets, stopping rule and decision criteria before execution. Keep critical safety and authorization failures separate from average quality; they cannot be compensated by a higher score.
  2. Validate the harness. Run a known-pass case, a known-fail case and a deliberate verifier/infrastructure failure. Confirm that each is classified correctly and that trace retention excludes credentials and private input bodies. If classification is wrong, fix the harness and repeat these checks before measuring the agent.
  3. Run the frozen cases. Use the same case definitions and budgets for baseline and candidate, with independent fixture state and recorded execution order. Retain every attempt and its run ID, outcome, reason, latency and resource totals. An exception is not evidence that an unsafe request was safely rejected.
  4. Investigate variation. Preserve the original failure. Classify disagreement as agent behavior, shared-state contamination, verifier ambiguity or an outage. Use only the predeclared repeat budget; do not retry until green, silently drop failures or change the expected outcome to fit the candidate. An unresolved harness fault makes the affected result inconclusive.
  5. Compare and decide. Report per-case results and uncertainty, regressions, critical failures and incomplete cases. Repeated runs of one case are not independent samples of the task distribution. A changed expectation needs a separately reviewed contract revision and reruns of both baseline and candidate; keep the old results.
  6. Fix and verify. Make a bounded fix, rerun the failing case to verify the mechanism, then rerun the applicable frozen regression suite from clean state. Stop at the declared budget if disagreement persists. Record pass, fail or inconclusive with the exact evidence; follow the project publication/deployment approval boundary separately.

Example: changed tool argument handling

A synthetic agent changes how it chooses a tenant identifier for a read-only lookup. Freeze three cases: an authorized lookup must return the seeded fixture, an unauthorized tenant must be rejected without a tool call, and a simulated tool outage must be classified as infrastructure failure. Supply neither real customer records nor production credentials.

Predeclare five repeats per case with fresh state, the same budget for baseline and candidate, and zero tolerance for an unauthorized tool call. Suppose the candidate returns the expected authorized result in all five runs but makes one unauthorized call in the second case: the candidate fails the permission contract even if its aggregate success rate improves. Retain that run, fix argument authorization, verify the negative case, and rerun the frozen suite. If the outage detector itself crashes, mark that case inconclusive and repair the detector before comparing versions. These are illustrative outcomes, not measured agent results.

Expected output:

contract: case-set revision, rules, repeat plan and budget
versions: baseline, candidate, model, prompt, tool and runtime
runs: one record per attempt, classified outcome and bounded evidence reference
comparison: per-case results, uncertainty, regressions and critical violations

…
FAQ

What are 'test cases'?

They are examples of situations with the responses the agent should give. They are used to verify if the agent is working correctly.

Why compare with a previous version?

To make sure new changes haven't broken something that already worked, ensuring the agent doesn't regress in quality.

Do I need to know how to code to use this?

No, you just need to be able to describe the test situations and what you expect as a response. The tool handles the technical part.

Details

Original description by the author

Evaluate agent behavior with versioned cases and explicit verifiers. Use when comparing agent or prompt changes, reproducing failures, or running agent regression tests.

repo: sickn33/agentic-awesome-skills

Popularity

GitHub stars
48k
Ranking position
#2043
License
MIT
Updated
10/15/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills