// Prepare an evaluation for PR submission as an entry to the register. Use when user asks to prepare an eval for submission or finalize a PR. Trigger when the user asks you to run the "Prepare Evaluation For Submission" workflow.
Create an evaluation report for a README by selecting models, estimating costs, running evaluations, and formatting results tables. Use when user asks to make/create/generate an evaluation report. Trigger when the user asks you to run the "Make An Evaluation Report" workflow.
CI and GitHub Actions maintenance workflows — fix a failing test from a CI URL, fix a failing smoke test, add @pytest.mark.slow markers to slow tests, or review a PR against agent-checkable standards. Use when user asks to fix a failing test, fix a smoke test, mark slow tests, or review a PR. Trigger when the user asks you to run the "Write a PR For A Failing Test", "Fix A Failing Smoke Test", "Mark Slow Tests", or "Review PR According to Agent-Checkable Standards" workflow.
Redirect to the inspect-evals-template for creating new evaluations. New evals are no longer created in this repository — they live in standalone repos. Use when user asks to create/implement/build a new evaluation.
Ensure test coverage for a single evaluation - both reviewing existing tests and creating missing ones. Analyzes testable components, checks tests against repository conventions, reports coverage gaps, and creates or improves tests. Use when user asks to check/review/create/add/ensure tests for an eval. Use whenever you are asked to review an evaluation that contains tests, or whenever you need to write a suite of tests. Do NOT use for fixing a specific failing CI test (use ci-maintenance-workflow instead).
Review a single evaluation's validity — whether its claims hold up, whether its name is accurate, whether samples can be both succeeded and failed at, and whether scoring measures ground truth. Use when user asks to check validity of an eval, or as part of the Master Checklist workflow. Do NOT use for code quality or test coverage (use eval-quality-workflow or ensure-test-coverage instead).
Audit a third-party Inspect AI evaluation for security risks before running it locally. Decide whether the eval is safe by checking for malicious host-side code, externally-fetched files that aren't quality-controlled, sandbox-breakout instructions, weak sandbox configuration, supply-chain hazards, credential exposure, resource exhaustion, and provenance signals. Use when the user asks to audit / vet / security-review an eval repo (GitHub URL or local path), or asks "is it safe to run X". Do NOT use for assessing whether an eval *measures what it claims* (use eval-validity-review) or for general code-quality review (use eval-quality-workflow / code-quality-review-all).
| name | prepare-submission-workflow |
| description | Prepare an evaluation for PR submission as an entry to the register. Use when user asks to prepare an eval for submission or finalize a PR. Trigger when the user asks you to run the "Prepare Evaluation For Submission" workflow. |
Since May 2026, new evaluations are submitted as entries to the register — the evaluation code lives in your own upstream repository, and you add a pointer to it here. Code is no longer added directly to src/inspect_evals/. If the user appears to be submitting evaluation code into the repo, direct them to register/README.md for the full process.
To prepare an evaluation for submission as a pull request:
The upstream repo must:
pyproject.toml with a [project] table so it can be installed via uv syncinspect_ai as a dependency@task decorator from inspect_aiAsk the user whether their upstream repo meets these requirements. Offer to check for them — if they provide the GitHub repository URL, fetch the repo's pyproject.toml and task files (e.g. via WebFetch on the raw GitHub URLs) to verify the requirements are met. If any requirement is not met, tell the user what needs to be fixed upstream before they can register.
register/<eval_name>/eval.yamlSkip this step if register/<eval_name>/eval.yaml already exists.
Use register/example_eval.yaml as the template — it documents every field. Don't ask the user field-by-field; instead, derive what you can from the upstream repo first, then ask one batched question for what's missing.
Hints on what to derive from the upstream repo (don't ask):
source.repository_url — from step 1.source.repository_commit — fetch the latest commit SHA on the default branch (must be a 40-char SHA, not a tag or branch).tasks[].name and tasks[].task_path — locate every @task-decorated function in the repo and record the function name and file path.title — from the upstream README heading or pyproject.toml [project].name.description — draft from the upstream README; keep to one short paragraph since the generated README links back upstream.source.maintainers — defaults to the repo owner; only override if the repo is org-owned and the real maintainers are individuals.tags — propose based on the eval's domain (e.g. Coding, games, tools). The upstream repo name is added automatically, so don't include it.Use register/example_eval.yaml to determine what additional questions are needed.
Show the user the drafted YAML for confirmation before writing the file. Do not set id — it is auto-injected from the directory name.
make check
This validates the eval.yaml and auto-generates a README.md next to it. The README is fully generated from eval.yaml — do not edit it by hand.
Because the generated page defers to upstream for details, make sure the upstream repo's README covers the dataset, scorer, task parameters, and how the eval was validated.
uv run scriv create
Use the PR template. The reviewer will ping anyone listed under source.maintainers for acknowledgement before merging.