mikasenghaas · Sep 16, 2026 · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026 · Sep 14, 2026
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/)).
-- **Scaffold environments**: create a new taskset/environment with `uv run init <name>` (`uv run init -h` lists options like `-T`/`-H`), and run evals with `uv run eval <taskset>`.
+- **Scaffold environments**: create a new taskset/environment with `uv run init <name>` (`uv run init -h` lists options like `-T`/`-H`), validate them model-free with `uv run validate <taskset>`, and evaluate them with prime-rl's `uv run eval <taskset>`.
 - **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`.
 
@@ -20,7 +20,7 @@
 
 ## Skills
 
-- **Use bundled skills first**: the skills in `skills/` cover the core workflows — `create-environments` (build or migrate a v1 taskset/environment/harness), `evaluate-environments` (configure and run evals), `release` (publish stable versions), and `brainstorm` (ideation and research planning). Reach for them before doing the work by hand.
+- **Use bundled skills first**: the skills in `skills/` cover the core workflows — `create-environments` (build or migrate a v1 taskset/environment/harness), `release` (publish stable versions), and `brainstorm` (ideation and research planning). Reach for them before doing the work by hand.
 
 ## Testing
 

diff --git a/configs/agentic_judge.toml b/configs/agentic_judge.toml
diff --git a/configs/alphabet_sort.toml b/configs/alphabet_sort.toml
diff --git a/configs/code_golf.toml b/configs/code_golf.toml
diff --git a/configs/deepwiki.toml b/configs/deepwiki.toml
diff --git a/configs/glossary.toml b/configs/glossary.toml
diff --git a/configs/gsm8k.toml b/configs/gsm8k.toml
diff --git a/configs/gsm8k_rlm.toml b/configs/gsm8k_rlm.toml
diff --git a/configs/harbor.toml b/configs/harbor.toml
diff --git a/configs/textarena.toml b/configs/textarena.toml
diff --git a/configs/wiki_search.toml b/configs/wiki_search.toml
diff --git a/configs/wiki_search_compact.toml b/configs/wiki_search_compact.toml
diff --git a/configs/wordle.toml b/configs/wordle.toml
diff --git a/docs/mint.json b/docs/mint.json
@@ -12,7 +12,6 @@
             "v1/getting_started",
             "v1/architecture",
             "v1/tasksets",
-            "v1/evaluation",
             "v1/harnesses",
             "v1/env",
             "v1/harbor",

diff --git a/docs/v1/evaluation.md b/docs/v1/evaluation.md
diff --git a/docs/v1/gepa.md b/docs/v1/gepa.md
@@ -35,10 +35,10 @@ Validate the config by using `uv run gepa @ config.toml --dry-run`. To run GEPA,
 
 ## Output
 
-Results go under `outputs/<env>--<model>--<harness>/<uuid>/`, matching `eval`.
+Results go under `outputs/<env>--<model>--<harness>--<short-id>/`.
 The best system prompt is printed when the run finishes and written to `best_system_prompt.txt` in that folder.
 
-Hand it back to eval or training via the config-layer taskset system prompt:
+Hand it back to evaluation or training via the config-layer taskset system prompt (prime-rl's `uv run eval`, or an `[[orchestrator.train.source]]`):
 
 ```bash
 uv run eval reverse-text \

diff --git a/docs/v1/getting_started.md b/docs/v1/getting_started.md
@@ -9,7 +9,7 @@ cd verifiers
 uv sync
 ```
 
-You can now run tasksets directly, e.g. `uv run eval <taskset-id>`, and scaffold new ones with `uv run init <name>`.
+Scaffold new tasksets with `uv run init <name>` and check them model-free with `uv run validate <taskset-id>`. Evaluations run through prime-rl: `uv run eval <taskset-id>` there (see prime-rl's `docs/training.md`).
 
 ## Skills
 

diff --git a/docs/v1/overview.md b/docs/v1/overview.md
@@ -38,7 +38,6 @@ A trace records the message graph, rewards, metrics, errors, and one per-call re
 - [Architecture](architecture.md) — How verifiers works behind-the-scenes
 - [Tasksets](tasksets.md) — How to create tasksets
   - [Harbor Tasksets](harbor.md) — How to create Harbor-based tasksets
-- [Evaluation](evaluation.md) — How to evaluate tasksets
 - [Harnesses](harnesses.md) — How to build custom harnesses
 - [Agent](agent.md) — How to run standalone agents
 - [Env](env.md) — How to build multi-agent environments
diff --git a/docs/v1/tasksets.md b/docs/v1/tasksets.md
@@ -116,7 +116,7 @@ A task's `hash` identifies its exact serialized data. Its `key` provides stable
 
 ## Lazy and infinite tasksets
 
-`load()` may be a generator instead of returning a list: yield each task as it's built. Consumers iterate the taskset lazily (`Taskset.head` pulls only what a run needs — `eval -n 5` builds 5 tasks, not the whole set) — so a generator pays off whenever building a task is expensive.
+`load()` may be a generator instead of returning a list: yield each task as it's built. Consumers iterate the taskset lazily (`Taskset.head` pulls only what a run needs — an eval of 5 tasks builds 5 tasks, not the whole set) — so a generator pays off whenever building a task is expensive.
 
 A procedural taskset can keep yielding forever. Declare `INFINITE = True` so consumers know the stream never ends — infinity is inherent to the taskset, not a config knob; how many tasks a run takes is the run's choice (`-n`), not the taskset's:
 
@@ -136,7 +136,7 @@ class AdditionTaskset(vf.Taskset[AdditionTask, vf.TasksetConfig]):
             )
 ```
 
-Two rules follow from infinity: a run over an infinite taskset must be bounded with `num_tasks` (`-n` on the CLI — omitting it is an error), and `shuffle` is an error: there is no whole set to sample from — bound the stream first (`taskset.head(n).shuffle()`). The generator runs once, client-side (the eval entrypoint or the prime-rl orchestrator pulls tasks off it and ships each task's data to the env server), so nothing needs to re-produce the same sequence across processes; keep `load()` deterministic only if you want `--resume` to regenerate the same first `n` tasks (see `alphabet_sort`, `color_codeword`, or the built-in `textarena` taskset).
+Two rules follow from infinity: a run over an infinite taskset must be bounded (prime-rl's `num_examples` / `-n` — omitting it is an error), and `shuffle` is an error: there is no whole set to sample from — bound the stream first (`taskset.head(n).shuffle()`). The generator runs once, client-side (the prime-rl orchestrator or evals process pulls tasks off it and ships each task's data to the env server), so nothing needs to re-produce the same sequence across processes; keep `load()` deterministic only if you want a resumed run to regenerate the same first `n` tasks (see `alphabet_sort`, `color_codeword`, or the built-in `textarena` taskset).
 
 ## Adding Tools
 

diff --git a/pyproject.toml b/pyproject.toml
@@ -34,7 +34,6 @@ dependencies = [
     "openai>=2.54.0,<3.0.0",
     "prime-tunnel>=0.1.8",
     "prime-sandboxes>=0.2.39",
-    "prime-runs>=0.1.2",
     "pydantic>=2.12.3",
     "rich>=11.0.0",
     "tenacity>=8.5.0",
@@ -147,12 +146,10 @@ ty = "2026-07-28T00:00:00Z"
 # PrimeIntellect-published on PyPI (trusted publisher)
 prime-tunnel = false
 prime-sandboxes = false
-prime-runs = false
 prime-pydantic-config = false
 renderers = false
 
 [project.scripts]
-eval = "verifiers.v1.cli.eval.main:main"
 validate = "verifiers.v1.cli.validate:main"
 debug = "verifiers.v1.cli.debug:main"
 replay = "verifiers.v1.cli.replay:main"
-Original file line number
+Diff line change
@@ Expand Up / @@ -9,7 +9,7 @@ cd verifiers @@
     uv sync
     ```
-    You can now run tasksets directly, e.g. `uv run eval <taskset-id>`, and scaffold new ones with `uv run init <name>`.
+    Scaffold new tasksets with `uv run init <name>` and check them model-free with `uv run validate <taskset-id>`. Evaluations run through prime-rl: `uv run eval <taskset-id>` there (see prime-rl's `docs/training.md`).
     ## Skills
@@ Expand Down @@