Agent Benchmark Skill for Claude

Framework for measuring and tracking agent response quality over time. Detects regressions before they reach production. Use when evaluating agent changes, auditing quality, or establishing performance baselines.

3k tokens

context cost

the whole folder, loaded on every use

files

instructions only

copies elsewhere

how many repositories repackaged it

521

stars on the repo

on the repository, not the skill itself

Install

one command, takes just this skill from the repository

npx skills add https://github.com/vibeeval/vibecosystem --skill agent-benchmark

The instruction itself

35 sections, as written by the author

Agent Benchmark Framework

Without benchmarks, we cannot know whether agent changes improve or degrade quality. This skill defines how to measure, track, and protect agent performance.

When to Activate

Before and after modifying any agent definition file
When adding a new skill that an agent depends on
Periodic quality audits (weekly/monthly)
When a user reports degraded agent output
Before promoting an agent from experimental to production

Core Concepts

Why Benchmarks Matter

Agent quality degrades silently. A prompt tweak that improves one response can break ten others. Without a baseline to compare against, every change is a guess. Benchmarks make quality visible and regressions detectable.

Benchmark Types

|------|-------|------|-----------|

Directory Structure

~/.claude/benchmarks/
  fixtures/
    code-reviewer/
      missing-error-handling.ts      # Input: code with no try/catch
      sql-injection.py               # Input: unparameterized query
      clean-code.ts                  # Input: code with no issues
    security-reviewer/
      hardcoded-secret.ts            # Input: API key in source
      parameterized-query.py         # Input: safe query (no findings expected)
    verifier/
      passing-build/                 # Input: project that builds
      failing-types/                 # Input: project with type errors
  ground-truth/
    code-reviewer/
      missing-error-handling.json    # Expected findings
      sql-injection.json             # Expected findings
      clean-code.json                # Expected: empty findings
    security-reviewer/
      hardcoded-secret.json
      parameterized-query.json
  rubrics/
    code-reviewer.md                 # Scoring rubric
    security-reviewer.md
    verifier.md
  baselines/
    code-reviewer-2026-03-01.json    # Timestamped baseline scores
    code-reviewer-2026-03-26.json
    security-reviewer-2026-03-26.json
  results/
    run-2026-03-26T14-00.json        # Latest run output

Scoring Rubric Template

Each agent has its own rubric file. The template:

## [Agent Name] Scoring Rubric

### Completeness (0-30 points)
Did the agent find everything it should have found?

- Found all expected issues: 30
- Missed 1 non-critical issue: 22
- Missed 1 critical issue: 10
- Missed 2+ issues: 5
- Found nothing when issues exist: 0

### Accuracy (0-30 points)
Were the findings correct? No false positives?

- All findings verified correct: 30
- 1 false positive: 22
- 2 false positives: 12
- 3+ false positives: 5
- Majority of findings are wrong: 0

### Actionability (0-20 points)
Did the agent give concrete, implementable fixes?

- Clear fix with file/line reference: 20
- Clear fix without location: 14
- Vague suggestion (refactor this): 7
- No fix suggested: 0

### Format Compliance (0-20 points)
Did the output follow the agent's output contract?

- Matches contract exactly (VERDICT + sections): 20
- Minor deviation (missing one section): 12
- Major deviation (no VERDICT): 5
- Unstructured free text: 0

Ground Truth Format

Ground truth files define what a correct agent response must contain:

{
  "fixture": "missing-error-handling.ts",
  "agent": "code-reviewer",
  "required_findings": [
    {
      "id": "missing-try-catch",
      "severity": "HIGH",
      "description_contains": ["error handling", "try", "catch"],
      "location_hint": "fetchUserData"
    }
  ],
  "forbidden_findings": [],
  "required_verdict": "FAIL",
  "min_score": 70
}

Scoring Logic

How a Run Is Scored

1. Load fixture (input code / task)
2. Run agent with fixture as input
3. Parse agent output
4. Check required_findings: each found = +completeness points
5. Check forbidden_findings: each false positive = -accuracy points
6. Check verdict matches required_verdict
7. Check format follows output contract
8. Sum scores → final 0-100
9. Compare against min_score threshold

Score Interpretation

| Score | Status | Action |

|-------|--------|--------|

| 90-100 | EXCELLENT | No action needed |

| 75-89 | GOOD | Minor tuning optional |

| 60-74 | WARN | Investigate degradation |

| 40-59 | POOR | Agent needs rework |

| 0-39 | CRITICAL | Block deployment |

Running Benchmarks

Run All Benchmarks

# Full suite
node ~/.claude/benchmarks/run.mjs

# Output: results/run-{timestamp}.json

Run Single Agent

# Benchmark one agent
node ~/.claude/benchmarks/run.mjs --agent code-reviewer

# With verbose output (shows actual vs expected per fixture)
node ~/.claude/benchmarks/run.mjs --agent code-reviewer --verbose

Compare Against Baseline

# Compare latest run against saved baseline
node ~/.claude/benchmarks/run.mjs --compare

# Compare specific run against specific baseline
node ~/.claude/benchmarks/run.mjs \
  --compare results/run-2026-03-26.json \
  --baseline baselines/code-reviewer-2026-03-01.json

Update Baseline

Only run this after verifying an improvement is real:

# Promote latest results to new baseline
node ~/.claude/benchmarks/run.mjs --baseline update

# Creates: baselines/{agent}-{date}.json

Regression Detection Rules

A regression is triggered when:

Score drops more than 10 points on any single fixture
Average score drops more than 5 points across all fixtures for an agent
A previously PASS fixture becomes FAIL
Format compliance drops below 80 (agent stopped following output contract)

Regression Report Format

REGRESSION DETECTED: code-reviewer

Fixture: sql-injection.py
  Baseline score:  88
  Current score:   61
  Delta:           -27 (CRITICAL)

  Missing finding: SQL injection in execute_query() line 14
  Root cause: Agent definition changed, removed security focus

  Recommendation: Revert agent change or add SQL injection examples

Metrics Tracked Per Agent

| Metric | Formula | Target |

|--------|---------|--------|

| accuracy | correct_findings / total_findings | >= 0.85 |

| completeness | found_issues / total_issues | >= 0.90 |

| false_positive_rate | false_positives / total_findings | <= 0.10 |

| format_compliance | correct_format_runs / total_runs | >= 0.95 |

| response_time_p50 | median seconds to complete | <= 30s |

| response_time_p95 | 95th percentile seconds | <= 60s |

| token_usage_avg | average tokens per run | tracked only |

| pass_rate | fixtures scoring above min_score | >= 0.80 |

Per-Agent Benchmark Definitions

code-reviewer

Fixtures: 6 (2 missing error handling, 2 code smell, 1 SQL injection, 1 clean code)

Pass threshold: 70/100

Critical findings: error handling, injection vulnerabilities, magic numbers

Non-critical findings: naming conventions, comment quality

security-reviewer

Fixtures: 8 (hardcoded secrets, injection flaws, auth bypass, safe code)

Pass threshold: 75/100

Zero tolerance: must find all HIGH/CRITICAL security issues

Acceptable miss: LOW severity cosmetic issues only

verifier

Fixtures: 4 (passing build, type errors, failing tests, lint errors)

Pass threshold: 80/100

Critical: must correctly identify PASS vs FAIL state

Scoring focus: verdict accuracy over prose quality

sleuth (bug investigator)

Fixtures: 5 (null pointer, race condition, wrong logic, correct code)

Pass threshold: 65/100

Critical: must identify root cause, not just symptom

Scoring focus: root cause analysis depth

Baseline Management

Baseline File Format

{
  "agent": "code-reviewer",
  "created_at": "2026-03-26T00:00:00Z",
  "commit": "abc1234",
  "scores": {
    "missing-error-handling": 88,
    "sql-injection": 92,
    "clean-code": 95,
    "code-smell-nesting": 79,
    "magic-numbers": 82,
    "dead-code": 76
  },
  "aggregate": {
    "average": 85.3,
    "min": 76,
    "max": 95,
    "pass_rate": 1.0
  }
}

Baseline Lifecycle

Create baseline → Make changes → Run benchmark →
Compare → PASS (no regression) → Update baseline
                               → FAIL (regression) → Fix and rerun

CI Integration

GitHub Actions Example

name: Agent Benchmark
on:
  push:
    paths:
      - '.claude/agents/**'
      - '.claude/skills/**'

jobs:
  benchmark:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run agent benchmarks
        run: node ~/.claude/benchmarks/run.mjs --compare

      - name: Comment PR with results
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v7
        with:
          script: |
            const results = require('./benchmark-output.json')
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              body: formatBenchmarkResults(results)
            })

      - name: Fail on regression
        run: |
          node ~/.claude/benchmarks/run.mjs --check-regression
          # Exits non-zero if regression > 10 points on any fixture

Benchmark Authoring Guide

Writing a Good Fixture

A good benchmark fixture is:

Realistic - Code that could exist in a real project
Focused - Tests one specific thing the agent should find
Unambiguous - The ground truth is objectively correct
Minimal - No unnecessary noise that could confuse the agent

Example: Good Fixture (code-reviewer)

// fixtures/code-reviewer/missing-error-handling.ts
// BENCHMARK: Agent must find missing error handling in fetchUser

async function fetchUser(id: string) {
  const response = await fetch(`/api/users/${id}`)
  const data = await response.json()
  return data
}

export default fetchUser

Ground truth:

{
  "required_findings": [{
    "severity": "HIGH",
    "description_contains": ["error handling", "network", "try"],
    "location_hint": "fetchUser"
  }],
  "required_verdict": "FAIL",
  "min_score": 70
}

Example: Bad Fixture (too complex)

Do not create fixtures with 10 different issues. The agent may find 7, miss 3, and you cannot tell if the misses are regressions or noise. One fixture = one primary concern.

Integration with Canavar

When a benchmark run produces a regression, log it to the Canavar error ledger:

node ~/.claude/hooks/dist/canavar-cli.mjs errors

Canavar cross-training means a regression in code-reviewer will inject a warning into all producer agents that use code-reviewer output, preventing cascading quality failures.

Quick Reference

# Before changing an agent:
node ~/.claude/benchmarks/run.mjs --agent code-reviewer --save-as before

# After changing the agent:
node ~/.claude/benchmarks/run.mjs --agent code-reviewer --compare before

# Full regression check:
node ~/.claude/benchmarks/run.mjs --compare --fail-on-regression

# Update baselines after confirmed improvement:
node ~/.claude/benchmarks/run.mjs --baseline update

Remember: A benchmark suite that is never run is decoration. Run benchmarks before every agent change. Protect quality proactively, not reactively.

Other skills for the same job

different authors, same section of the catalogue

Skill Creator

by anthropics

vendor ×10

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

This skill should be used when working with reinforcement learning tasks including high-performance RL training, custom environment development, vectorized parallel simulation, multi-agent systems, or integration with existing RL environments (Gymnasium, PettingZoo, Atari, Procgen, etc.). Use this skill for implementing PPO training, creating PufferEnv environments, optimizing RL performance, or developing policies with CNNs/LSTMs.

Run evaluations for one, multiple, or all skills using the agent orchestration framework. Make sure to use this skill whenever the user asks to run evals, test a skill's performance, run benchmarks, or compare baseline versus with-skill execution.

2k tokens

LLM Application Dev Prompt Optimize

by ComeOnOliver

×2

You are an expert prompt engineer specializing in crafting effective prompts for LLMs through advanced techniques including constitutional AI, chain-of-thought reasoning, and model-specific optimizati

6k tokens

Nowait Reasoning Optimizer

by ComeOnOliver

×2

Implements the NOWAIT technique for efficient reasoning in R1-style LLMs. Use when optimizing inference of reasoning models (QwQ, DeepSeek-R1, Phi4-Reasoning, Qwen3, Kimi-VL, QvQ), reducing chain-of-thought token usage by 27-51% while preserving accuracy. Triggers on "optimize reasoning", "reduce thinking tokens", "efficient inference", "suppress reflection tokens", or when working with verbose CoT outputs.

8k tokens scripts

Evolving AI Agents

by Orchestra-Research

×1

Provides guidance for automatically evolving and optimizing AI agents across any domain using LLM-driven evolution algorithms. Use when building self-improving agents, optimizing agent prompts and skills against benchmarks, or implementing automated agent evaluation loops.

Elite AI context engineering specialist mastering dynamic context management, vector databases, knowledge graphs, and intelligent memory systems.

2k tokens

Zach Seller Skill Creator

by zach22-1999

×1

亚马逊卖家专用的 skill 创建器（中文）。当用户想把一个亚马逊运营/自媒体/日常工作流程变成可复用的 skill 时使用。触发场景包括但不限于：用户说"我想做一个 skill""把这个流程变成 skill""帮我写个自动化""优化我已有的 skill""给这个工作流做个自动化"，即使用户没用"skill"这个词，只要在描述"以后每次都这样做"的重复性工作时也应触发。本 skill 的核心差异：强制用户先回答 6 个业务问题（业务目标/过去做法/具体步骤/方法论/调用方式/期望输出）再进入创建流程，防止产出空洞 skill。Create new skills, improve existing skills, run evals and benchmarks — tailored for Amazon sellers with a Chinese-first workflow.

63k tokens scripts zh

How to use it

Copy the folder

Take vibeeval/agent-benchmark from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.