// Review verifiers environments for correctness, robustness, and ecosystem compatibility. Use when asked for environment code review, quality audit, migration validation, or release readiness checks for local environments or environments pulled from the Hub.
Create or migrate verifiers environments for the Prime Lab ecosystem. Use when asked to build a new environment from scratch, port an eval or benchmark from papers or other libraries, start from an environment on the Hub, or convert existing tasks into a package that exposes load_environment and installs cleanly with prime env install.
Discover and inspect verifiers environments through the Prime ecosystem. Use when asked to find environments on the Hub, compare options, inspect metadata, check action status, pull local copies for inspection, or choose environment starting points before evaluation, training, or migration work.
Train models with verifiers environments using hosted RL or prime-rl. Use when asked to configure RL runs, tune key hyperparameters, diagnose instability, set up difficulty filtering, or create practical train and eval loops for new environments.
Run and analyze evaluations for verifiers environments using prime eval. Use when asked to smoke-test environments, run benchmark sweeps, resume interrupted evaluations, compare models, inspect sample-level outputs, or produce evaluation summaries suitable for deciding next steps.
Optimize environment system prompts with GEPA through prime gepa run. Use when asked to improve prompt performance without gradient training, compare baseline versus optimized prompts, run GEPA from CLI or TOML configs, or interpret GEPA outputs before deployment.
Run interactive brainstorming across verifiers environments, evaluations, GEPA, and RL training. Use when the user wants ideation, literature scanning, concept teaching, roadmap planning, or research program design grounded in local CLI sources, verifiers, and RL trainer code.
| name | review-environments |
| description | Review verifiers environments for correctness, robustness, and ecosystem compatibility. Use when asked for environment code review, quality audit, migration validation, or release readiness checks for local environments or environments pulled from the Hub. |
Find correctness risks and regressions first, then assess maintainability and ecosystem compliance.
./environments/<env_name>.prime env pull owner/name.load_environment(...)SingleTurnEnv, MultiTurnEnv, ToolEnv/MCPEnv/StatefulToolEnv, SandboxEnv/PythonEnv, V1 vf.Env with explicit vf.Taskset/vf.Harness objects for framework programs, CliAgentEnv for sandboxed agents)--skip-upload unless the user explicitly requests that deviation; standard runs save automatically for the private Evaluations tab and prime eval view:prime env install <env>
prime eval run <env> -m openai/gpt-4.1-mini -n 5
configs/endpoints.toml for reproducible review runs.api_client_type when reviewing non-default providers. openai_chat_completions is the default; openai_responses and anthropic_messages should be explicit in endpoint configs when those protocols are required.gpt-4.1 series, qwen3 instruct series.gpt-5 series, qwen3 thinking series, glm series.0.0 reward when the model fails the task.load_environment().vf.Env / vf.Taskset / vf.Harness boundary, with load_taskset(config: MyTasksetConfig) and optional load_harness(config: MyHarnessConfig) defining child config types, plus the canonical load_environment(config: vf.EnvConfig) shim delegating through vf.load_taskset(config=config.taskset) and vf.load_harness(config=config.harness).prime env init my-env --v1 shape: task settings in TasksetConfig, tasks in load_tasks, task-owned tools in load_toolsets, user behavior in User subclasses, lifecycle/metrics/rewards as @vf.* methods, and typed component entrypoints through load_taskset, optional load_harness, and load_environment.Task data is serializable, state remains serializable at rollout boundaries, and model/client controls flow through runtime state rather than top-level dataset columns.state.get_endpoint_config(api="chat") rather than hardcoding an upstream LLM endpoint. For CliAgentEnv agents, verify sandboxed agent code consumes the injected interception endpoint; the proxy is what makes rollouts visible to the rubric.load_environment() with vf.ensure_keys(...).pyproject.toml, README/docs references, package include paths, tests, and generated AGENTS output were updated together.EnvConfig just to narrow child config types, and avoid root env config knobs.Return findings first, sorted by severity:
P0/P1 bugs and behavioral mismatches.P2 quality risks and maintainability issues.State explicitly that no defects were found, then list residual risk and untested areas.