Writing a benchmark task
A task is one folder plus one registry line, like a check.
A task is one folder plus one registry line, like a check.
- Create
packages/benchmarks/src/tasks/<id>/with:task.json: validated bytaskManifestSchema(id,version,title,category,estimatedScope,params,preconditions, andcriteria.pass/partial/fail).prompt.md: the fixed prompt users paste into their coding agent. Use{{param}}placeholders only for declared params. Keep it agent-neutral; never name a vendor.verify.ts:export default defineTask({ manifest, prompt, prepare?, verify }).prepareruns atomot bench start, checks preconditions (throwTaskPreconditionError), and returns JSON data saved as the baseline.verifyreturns{ outcome: "pass" | "partial" | "fail", reasons: string[] }.
- Add one line to
packages/benchmarks/src/registry.ts. - Add
docs/benchmarks/<id>.md(CI fails without it). Start the file with YAML frontmatter containingtitle: <id>and, when useful, a one-linedescription:; do not add a duplicate# <id>heading. - Add pass, partial, and fail tests in
packages/benchmarks/test/<id>.test.tsusing thestartTask/verifyTaskhelpers, which build throwaway git repos.
Verifiers use the context: changedFiles() (working tree versus the baseline commit, excluding .omot/), read/readBaseline, runScript(name) with the detected package manager, and runPackageBin(pkg, args) for locally installed tools. They must not make network calls or modify the repository.
Any change to prompt.md or verify.ts of an existing task needs a version bump in task.json, so results from different versions are never mixed. CI checks this with packages/benchmarks/scripts/check-task-versions.mjs.
Example benchmark page frontmatter:
---
title: add-unit-test
description: Add unit tests for an untested function.
---