agentleFS
allenaiallenai/vla-evaluation-harness/skills/add-benchmark/SKILL.md

add-benchmark

Skill677 starsChanged 8 months agoApache-2.0View on GitHub

Add or improve a simulation benchmark in vla-eval, including evaluation protocol, assets, adapter lifecycle, and runtime validation.

4 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions4 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 4

    1. NVIDIA-NeMo/Gym★ 1.3ksame name
    2. huggingface/paperswithcode★ 315same name
    3. ory/lumen★ 254same name
    4. microsoft/Sico★ 253same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository5 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use vla_eval.dirs.assets_cache("<benchmark>").

    line 34
  2. Very specific:

    Use ensure_license for gated assets.

    line 44
  3. Distinctive:

    Check the intended runtime's write permissions, including read-only images.

    line 46
  4. Very specific:

    Follow docs/render-backends.md.

    line 47
  5. Very specific:

    Add configs under configs/benchmarks/<name>/ per configs/README.md.

    line 56
  6. Distinctive:

    Check reset correctness and resource accumulation before optimizing env creation.

    line 69
  7. Very specific:

    Keep task/variation/episode identity independent of shard assignment.

    line 70
  8. Very specific:

    Run make check, make test, and uv run vla-eval test --validate.

    line 79
  9. Very specific:

    Use --dev for local adapter edits or rebuild the image.

    line 86

“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 a benchmark

Work from the target harness checkout; paths below are relative to it. Read AGENTS.md, CONTRIBUTING.md, and a comparable adapter/config. For an existing integration, use the affected sections and preserve unrelated behavior.

1. Evaluation protocol

Trace the upstream evaluator: task selection → initialization → rollout → success check → cleanup. Establish:

  • Version, task/variation set, initial-state selection, and seeds.
  • Robot/controller, observations, action format, and control frequency.
  • Warm-up, task-specific horizons, termination, success, and aggregation.

Inspect helper side effects: an expert rollout may select solvable states and initialize fields needed by success checks. Preserve those functions without blindly repeating expensive work. Bound setup retries; report failures instead of silently changing the evaluated population. Document intentional protocol deviations.

2. Runtime and assets

MaterialPlacement and setup
Simulator dependenciesdocker/Dockerfile.<name>; register in docker/build.sh and docker/push.sh. Pin compatible revisions and verify actual imports.
External scenes/dataPersistent cache via existing download mechanisms; record source, version, required contents, and acquisition command.
Generated filesWritable scratch/output paths, separate from immutable assets; libraries may try to write beside installed assets.

Use vla_eval.dirs.assets_cache("<benchmark>"). Its root follows VLA_EVAL_ASSETS_CACHE → VLA_EVAL_HOME/assets → ${XDG_CACHE_HOME:-~/.cache}/vla-eval/assets. Config mounts must map the host cache to the simulator's container path with the same precedence.

For a working mount/download example, inspect configs/benchmarks/behavior1k/eval.yaml and Behavior1KBenchmark._ensure_assets in src/vla_eval/benchmarks/behavior1k/benchmark.py.

  • Reuse complete caches; coordinate lazy downloads or prepare them before shards.
  • Use ensure_license for gated assets. User acceptance is passed through --accept-license <id> or VLA_EVAL_ACCEPTED_LICENSES; do not assume consent.
  • Check the intended runtime's write permissions, including read-only images.
  • Follow docs/render-backends.md; verify real camera output before declaring renderer support. Successful environment creation is insufficient.

3. Benchmark adapter

Implement StepBenchmark (or VectorStepBenchmark for a simulator that steps many environments per call, see docs/rfcs/0009-vector-benchmarks.md) under src/vla_eval/benchmarks/<name>/, following the current src/vla_eval/benchmarks/base.py contracts. Keep simulator imports lazy. Add configs under configs/benchmarks/<name>/ per configs/README.md.

BoundaryResponsibility
ObservationsNamed cameras, language, optional state; preserve image content. Policy resize/crop belongs with model preprocessing.
Requested inputsForward model-requested wrist/state settings through wrappers; explicit benchmark config takes precedence. Verify delivery to the server.
ActionsMap controller, absolute/delta convention, frame, rotation, units, and gripper semantics. Apply each conversion in one layer.
ResultsDeclare specs and metric aggregation; supply recording data through the harness, keeping recording policy out of the adapter.
TimeSet step_dt (env seconds per step: control period × env steps per action) only when verified from upstream source; else leave None.

4. Reset, termination, and episode identity

  • Match upstream reuse/reconstruction and cleanup, including interrupted episodes. Check reset correctness and resource accumulation before optimizing env creation.
  • Keep task/variation/episode identity independent of shard assignment. Compare representative initial images/states across resets; one seeded RNG may not cover robot, scene, and object initialization. Document residual nondeterminism.
  • Reconcile task-specific limits with the runner cap to avoid truncating valid episodes. Separate simulation-step limits from wall-clock watchdogs.
  • Preserve success predicates and distinguish task failure from infrastructure error.

5. Validation and handoff

Run make check, make test, and uv run vla-eval test --validate; confirm the config appears in uv run vla-eval test --list. When runtime execution is authorized:

uv run vla-eval test -c configs/benchmarks/<name>/<config>.yaml --dev

Use --dev for local adapter edits or rebuild the image. Exercise representative task paths and consecutive episodes. Inspect images/state, action effects, termination, resource growth, and shard coverage; compare upstream behavior using a released baseline or replay when available.

Host tests/ is for simulator-independent harness logic. Do not add host pytest cases that import container-only benchmark adapters, install simulator dependencies on the host to run them, or fake those dependencies through sys.modules. Validate adapter code through smoke/integration runs inside the real benchmark image. An echo-policy smoke proves plumbing, not simulator fidelity or reproduced performance.

Deliver asset instructions, runnable configs, supported runtime/rendering, protocol deviations, and separate statements of structural, runtime, and reproduction checks.

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.