メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
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).
Fix code quality issues identified in a code quality review stored in agent_artefacts/code_quality/<topic>/. Systematically addresses issues found by the code-quality-review-all skill for ANY code quality topic, with validation and testing at each step. Use when user asks to fix issues from a code quality review, or asks to fix issues from agent_artefacts/code_quality/<topic>.
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.
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).
| 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.
Important: The submitter must be the owner or a maintainer of the upstream repository. The submission workflow enforces this — if they are not, they will need to fork the repo so they can be listed as a maintainer.
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.
Use register/example_eval.yaml to determine what additional questions are needed. Note: contributors and tags are deprecated fields — do not include them in new submissions.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.