mikasenghaas · Nov 3, 2026 · Sep 15, 2026 · Sep 15, 2026 · Nov 3, 2026 · Nov 3, 2026
diff --git a/.markdownlint-cli2.yaml b/.markdownlint-cli2.yaml
@@ -28,11 +28,6 @@ overrides:
       MD007: false
       MD029: false
     combine: merge
-  - filter:
-      - skills/evaluate-environments/SKILL.md
-    config:
-      MD029: false
-    combine: merge
   - filter:
       - verifiers/envs/experimental/composable/tasksets/swe/README.md
     config:

diff --git a/AGENTS.md b/AGENTS.md
@@ -9,7 +9,7 @@
 ## Running code
 
 - **Always use uv**: run code and commands with `uv run`, never raw `python`. Make sure `uv` is installed ([docs](https://docs.astral.sh/uv/getting-started/installation/)).
-- **Run evals**: run a taskset with `uv run vf-eval <taskset>`.
+- **Check tasksets**: check a taskset without a model with `uv run vf-validate <taskset>`. Run model evals with prime-rl's `uv run eval`.
 - **Validate TOML first**: validate config `.toml` files before running them.
 - **Don't add dependencies**: never add dependencies or optional extras to the top-level `pyproject.toml`.
 

diff --git a/docs/building-environments.md b/docs/building-environments.md
@@ -6,7 +6,7 @@ An environment package defines the tasks an agent receives, the files and tools
 
 A verifiers evaluation spans up to four execution boundaries:
 
-- **The evaluator** (the machine running `vf-eval` or an environment worker) loads datasets, runs Python task hooks (`setup`, `finalize`, `@vf.reward`), coordinates agents, and records traces.
+- **The evaluator** (the machine running the environment server) loads datasets, runs Python task hooks (`setup`, `finalize`, `@vf.reward`), coordinates agents, and records traces.
 - **The agent sandbox** (the agent's configured [runtime](runtimes.md#capability-matrix)) runs the harness, holds the task workspace, and executes any commands the agent invokes.
 - **The grading sandbox** is a fresh container started after the agent finishes when you use isolated scoring (`ScoringConfig(mode="isolated")`), giving graders a clean filesystem containing only declared agent outputs and private test assets.
 - **Task tools** run in their own configured runtime by default, inside the agent sandbox when configured with `colocated = true`, inside a named task service when configured with `service = "<name>"`, or on a Prime VM of their own, under its own egress policy, when their `runtime` is a Prime runtime beside a Prime workspace.
@@ -188,9 +188,7 @@ Install your new package into the CLI environment and run a quick smoke test bef
 
 ```bash
 uv pip install -e environments/file_sum
-uv run vf-eval @ file-sum.toml --dry-run
 uv run vf-validate file-sum --runtime.type docker -n 1
-uv run vf-eval @ file-sum.toml -n 1 -r 1 -c 1
 ```
 
-`--dry-run` validates the TOML config and taskset resolution without starting containers. Next, `vf-validate` runs your task's `validate` hook and a no-op check inside a single sandbox to confirm that the gold answer scores `1.0` while an untouched workspace scores `0.0`. Because `vf-validate` exercises `Task` directly in one sandbox, it does not transfer artifacts or call `stage_verifier` automatically; if your gold check needs to exercise the full isolated-grading flow without a model, request `trace` by name in `validate`, finalize the submission, and call `await vf.grade_submission(self, trace, runtime)` (or call `await self.stage_verifier(runtime)` directly). Finally, running a single rollout with `vf-eval -n 1 -r 1 -c 1` exercises the full solver-to-verifier transfer lifecycle; see [debugging](debugging.md) for inspecting saved traces and diagnosing setup or grading errors.
+`vf-validate` runs your task's `validate` hook and a no-op check inside a single sandbox to confirm that the gold answer scores `1.0` while an untouched workspace scores `0.0`. Because `vf-validate` exercises `Task` directly in one sandbox, it does not transfer artifacts or call `stage_verifier` automatically; if your gold check needs to exercise the full isolated-grading flow without a model, request `trace` by name in `validate`, finalize the submission, and call `await vf.grade_submission(self, trace, runtime)` (or call `await self.stage_verifier(runtime)` directly). Finally, running a single rollout with [`uv run eval` in prime-rl](https://github.com/PrimeIntellect-ai/prime-rl/blob/main/docs/eval.md) exercises the full solver-to-verifier transfer lifecycle; see [debugging](debugging.md) for inspecting saved traces and diagnosing setup or grading errors.
diff --git a/docs/debugging.md b/docs/debugging.md
@@ -4,33 +4,30 @@ verifiers includes CLI tools to validate task setup and scoring before spending
 
 ## Before running an agent
 
-Before launching a full evaluation, you can verify your configuration, task setup, reference solutions, and scoring logic directly against a runtime:
+Before launching a full evaluation, you can verify your task setup, reference solutions, and scoring logic directly against a runtime:
 
 ```bash
-uv run vf-eval my-task --dry-run
 uv run vf-validate my-task -n 1 --only-setup
 uv run vf-validate my-task -n 1 --only-gold
 uv run vf-validate my-task -n 1 --only-noop
 uv run vf-debug my-task -n 1 --command 'pwd && ls -la'
 ```
 
-`vf-eval --dry-run` resolves and saves the configuration without loading dataset rows or starting sandboxes.
-
 `vf-validate` boots the configured runtime and runs task checks without an agent:
 
 - `--only-setup` runs `Task.setup(runtime)` to verify that containers, files, and background services start cleanly.
 - `--only-gold` runs `setup` followed by `Task.validate(runtime)` to check a reference answer or solution; `validate` can also request the check's `trace` by name. `validate` returns `True` (valid), `False` (invalid), or `None` when the task defines no gold check (reported as `unchecked` rather than a pass).
 - `--only-noop` runs `setup`, `finalize`, and task scoring on the untouched environment. Any task that already scores `1.0` or higher with no agent actions is flagged as `invalid` (lower partial rewards pass the check and are recorded in the results, while tasks with no reward are marked `unchecked`).
 
-When you run `vf-validate` without an `--only-*` flag, it runs both the gold and noop checks in separate runtimes. Because validation runs directly against the task rather than through a harness or `Env`, it does not apply harness network restrictions, transfer artifacts, or invoke `stage_verifier`. If your gold check relies on private tests, call your staging helper inside `Task.validate`, and use a real `vf-eval` run to test the full isolated-grading lifecycle.
+When you run `vf-validate` without an `--only-*` flag, it runs both the gold and noop checks in separate runtimes. Because validation runs directly against the task rather than through a harness or `Env`, it does not apply harness network restrictions, transfer artifacts, or invoke `stage_verifier`. If your gold check relies on private tests, call your staging helper inside `Task.validate`, and use a real prime-rl eval run to test the full isolated-grading lifecycle.
 
 Validation writes `results.jsonl`, `summary.json`, `logs/validate.log`, and `configs/resolved/validate.json`. You can re-run missing, errored, or timed-out checks in place with `--resume`:
 
 ```bash
 uv run vf-validate @ <run-dir>/configs/resolved/validate.json --resume
 ```
 
-For interactive troubleshooting, `vf-debug` runs `Task.setup` and then executes a one-off shell `--command` or uploaded `--script-path check.sh` inside the runtime before tearing it down. Because neither `vf-validate` nor `vf-debug` wraps the task in an `Env`, both take top-level `--taskset.*` and `--runtime.*` flags (rather than `vf-eval`'s `--env.taskset.*` and `--env.agent.runtime.*`), alongside [`--select.*`](tasksets.md#selecting-tasks) to filter tasks. Note that both commands execute real task setup (which may spin up paid sandboxes), and `vf-validate`'s noop check will call any configured judges.
+For interactive troubleshooting, `vf-debug` runs `Task.setup` and then executes a one-off shell `--command` or uploaded `--script-path check.sh` inside the runtime before tearing it down. Because neither `vf-validate` nor `vf-debug` wraps the task in an `Env`, both take top-level `--taskset.*` and `--runtime.*` flags, alongside [`--select.*`](tasksets.md#selecting-tasks) to filter tasks. Note that both commands execute real task setup (which may spin up paid sandboxes), and `vf-validate`'s noop check will call any configured judges.
 
 ## Re-score without rerunning the agent
 

diff --git a/docs/evaluation.md b/docs/evaluation.md
diff --git a/docs/gepa.md b/docs/gepa.md
@@ -8,7 +8,7 @@ uv run vf-gepa reverse-text
 
 `vf-gepa` alternates between running rollouts on the taskset and asking a reflection LLM to review the trajectories and propose improvements to `TaskData.system_prompt`.
 
-GEPA reuses the same `env` (taskset + agent), `client`, and `sampling` configuration as `vf-eval`, so its `.toml` config looks almost identical:
+GEPA takes the same `env` (taskset + agent), `client`, and `sampling` configuration as a prime-rl eval:
 
 ```toml
 model = "deepseek/deepseek-v4-flash"
@@ -27,7 +27,7 @@ Validate the config with `uv run vf-gepa @ config.toml --dry-run`, and run optim
 
 ## Common config values
 
-- `model` / `-m` — model for the rollouts under optimization (default: `deepseek/deepseek-v4-flash`, same as `vf-eval`)
+- `model` / `-m` — model for the rollouts under optimization (default: `deepseek/deepseek-v4-flash`)
 - `reflection_model` / `reflection_client` — teacher model and endpoint that propose new prompts (default: reuse `model` and `client`)
 - `select` — [task selection](tasksets.md#selecting-tasks) applied before splitting into train and validation sets (shuffling is off by default)
 - `num_train` / `num_val` — train tasks for reflection minibatches and validation tasks for scoring candidates on the Pareto frontier (defaults: `100` / `50`)
@@ -38,14 +38,9 @@ Task selection runs before the train/val split: the first `num_train` selected t
 
 ## Output
 
-Results are written to `output_dir / run.dir`, which defaults to `outputs/<env>--<model>--<harness>--<short-id>/` just like `vf-eval`. The resolved config is saved at `configs/resolved/gepa.json`, and when the run finishes, the best system prompt is printed to the console and written to `best_system_prompt.txt`.
+Results are written to `output_dir / run.dir`, which defaults to `outputs/<env>--<model>--<harness>--<short-id>/`. The resolved config is saved at `configs/resolved/gepa.json`, and when the run finishes, the best system prompt is printed to the console and written to `best_system_prompt.txt`.
 
-You can pass that file directly back into evaluation or training via `--env.taskset.system-prompt`:
-
-```bash
-uv run vf-eval reverse-text \
-  --env.taskset.system-prompt outputs/<run>/best_system_prompt.txt
-```
+Pass that file back into evaluation or training through the taskset's `system_prompt` config field.
 
 ## Limitations
 

diff --git a/docs/getting_started.md b/docs/getting_started.md
@@ -9,27 +9,25 @@ cd verifiers
 uv sync
 ```
 
-The checkout installs the example tasksets right away, so you can verify your setup with a local dry run that doesn't call a model:
+The checkout installs the example tasksets right away, so you can verify your setup with a local check that doesn't call a model:
 
 ```bash
-uv run vf-eval reverse-text --env.agent.harness.id null \
-  --env.agent.runtime.type subprocess --dry-run
+uv run vf-validate reverse-text -n 1
 ```
 
-For full model evaluations, we recommend [`uv run eval` in prime-rl](https://github.com/PrimeIntellect-ai/prime-rl/blob/main/docs/eval.md), which is replacing the bundled `vf-eval` CLI.
+To run model evaluations, use [`uv run eval` in prime-rl](https://github.com/PrimeIntellect-ai/prime-rl/blob/main/docs/eval.md).
 
 To work with other tasksets, including packages you build yourself following [building environments](building-environments.md#create-a-package), install them into the environment first (for example, `uv pip install -e environments/<package_dir>`) so the CLI can resolve their IDs. Harbor-based tasksets require Python 3.12+ and the `harbor` extra (`uv sync --extra harbor`).
 
 ## Commands
 
-verifiers installs five CLI commands, which you run with `uv run` in the environment where verifiers and your taskset package are installed:
+verifiers installs four CLI commands, which you run with `uv run` in the environment where verifiers and your taskset package are installed:
 
 | Command | Use |
 | --- | --- |
 | [`vf-validate <taskset>`](debugging.md#before-running-an-agent) | Check task setup, a known gold solution, or the untouched task |
 | [`vf-debug <taskset>`](debugging.md#before-running-an-agent) | Run a command or script inside the prepared task runtime |
-| [`vf-replay <run-dir>`](debugging.md#re-score-without-rerunning-the-agent) | Re-score saved `vf-eval` traces without recreating their sandbox |
+| [`vf-replay <run-dir>`](debugging.md#re-score-without-rerunning-the-agent) | Re-score saved traces without recreating their sandbox |
 | [`vf-gepa <taskset>`](gepa.md) | Optimize a system prompt against task rewards |
-| [`vf-eval <taskset>`](evaluation.md) | Run the bundled evaluator |
 
-Pass `--help` to any command to inspect its flags. Because tasksets and harnesses register their own options dynamically, include the taskset and harness IDs before `--help` when checking evaluation flags (note that `vf-validate` and `vf-debug` take `--taskset.*` and `--runtime.*`, whereas `vf-eval` nests them under `--env.taskset.*` and `--env.<agent>.runtime.*`).
+Pass `--help` to any command to inspect its flags. Because tasksets and harnesses register their own options dynamically, include the taskset ID before `--help` to see the taskset's flags.