agentleFS
MicrosoftKnown publishermicrosoft/Sico/labs/AgentStream/exgentic/misc/skills/add-benchmark/SKILL.md

add-benchmark

Skill253 starsChanged 5 months agoMITView on GitHub

Use when adding or updating a benchmark adapter in the Exgentic repository. Follow the repository benchmark principles, keep the benchmark contract protocol-agnostic, prefer the thinnest possible wrapper that makes the benchmark accessible to any Exgentic agent, reuse external harness assets and scoring where possible, and validate the adapter with representative smoke tests before finishing.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 9 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when working on benchmark adapters in the Exgentic repository.

    line 8
  2. Distinctive:

    Keep the agent-facing contract protocol-agnostic.

    line 26
  3. Distinctive:

    Do not define the benchmark in terms of one provider's chat or tool-calling format.

    line 27
  4. Distinctive:

    Prefer the thinnest possible wrapper.

    line 29
  5. Very specific:

    Prefer a benchmark module, a setup.sh, and a registry entry with clear responsibilities.

    line 36
  6. Distinctive:

    Check task listing, subset listing, happy-path scoring, failure-path scoring, and error semantics.

    line 39
  7. Distinctive:

    Prefer the thinnest wrapper that preserves the benchmark's meaning.

    line 46
  8. Very specific:

    Use finish only when it is part of the benchmark contract.

    line 48
  9. Distinctive:

    If outputs are not real execution results, say so plainly in the benchmark contract.

    line 49
  10. Distinctive:

    Keep success, unsuccessful completion, unfinished runs, and errors distinct.

    line 50
  11. Distinctive:

    Before finishing, run at least:

    line 54

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

Add Benchmark

Use this skill when working on benchmark adapters in the Exgentic repository.

First read

Start with:

  • docs/adding-benchmarks.md
  • src/exgentic/core/benchmark.py
  • src/exgentic/interfaces/registry.py

Then inspect the most relevant existing adapters:

  • src/exgentic/benchmarks/tau2/tau2_benchmark.py
  • src/exgentic/benchmarks/bfcl/bfcl_benchmark.py

Workflow

  1. Define the benchmark contract before writing code. Decide the real task, the agent-relevant context, the semantic actions, the finish condition, and the scoring boundary.
  2. Keep the agent-facing contract protocol-agnostic. Do not define the benchmark in terms of one provider's chat or tool-calling format.
  3. Prefer the thinnest possible wrapper. Make the benchmark accessible to any Exgentic agent with the minimum translation surface necessary. Do not add extra abstraction, copied logic, or runtime machinery unless it is needed to preserve benchmark meaning.
  4. Decide the source-of-truth boundary. Reuse external benchmark assets, setup, and scoring where possible, but do not let an external harness dictate the wrong runtime contract for Exgentic.
  5. Implement runtime, setup, and registration separately. Prefer a benchmark module, a setup.sh, and a registry entry with clear responsibilities.
  6. Validate the adapter as a benchmark, not just as code. Check task listing, subset listing, happy-path scoring, failure-path scoring, and error semantics.

Non-negotiable rules

  • task must be the actual task.
  • context must include only what the agent should know.
  • subset names and internal metadata stay out of context.
  • Prefer the thinnest wrapper that preserves the benchmark's meaning.
  • Actions should describe semantic operations, not protocol artifacts.
  • Use finish only when it is part of the benchmark contract.
  • If outputs are not real execution results, say so plainly in the benchmark contract.
  • Keep success, unsuccessful completion, unfinished runs, and errors distinct.

Validation

Before finishing, run at least:

  • python -m py_compile on changed benchmark files
  • pre-commit run --files ...
  • git diff --check

Also run benchmark-specific smoke tests that prove:

  • one passing case works
  • one failing case is represented correctly
  • one real error is surfaced as an error

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.