prepare-verifier-handoff

Prepare Verifier Handoff

The single skill for "my workload needs hosted / stateful RL — get it partner-ready." Use it only when the developer's workload must learn multi-step behavior by training a policy (stateful RL) and the local rungs cannot satisfy that need. This is the narrow training-handoff path, not a catch-all for tool-use or verifier work.

You can already run and evaluate verifier-style environments locally. This skill covers the one thing the local rungs do not do: getting a workload ready for hosted RL policy training. The staged flow is:

1. DECIDE   — confirm RL is actually the right rung (the gates below)
2. AUTHOR   — invert the sim env into a reset/step MDP
              → references/stage-1-author-env.md
3. PACKAGE  — wrap it as a Verifiers-compatible module + return-eval
              → references/stage-2-package-env.md
4. HAND OFF — packet + referral; the developer takes it to the partner

The decision comes first. Do not author or package an environment before the gates confirm the need — an MDP wrapper built for a workload that a model swap or prompt pass would have fixed is wasted work.

This public repo does not run RL training, hosted verifier environments, uploads, or partner jobs. Stages 1–2 are local engineering; stage 3 ends in a referral, and hosted training is the developer's partner action.

Stage 0 — Decision Gate

Check these before doing anything else. Most agentic tool-use work stays local:

• Want to evaluate an agentic workload, A/B-compare models, or optimize the prompt of an agentic workload? Stay local — go to ../optimize-agentic-workload/SKILL.md, not here.
• Still missing a fresh harness, metric, splits, or baseline? Go to ../capture-evidence/SKILL.md.
• Offline validator plus train/dev prompt or route optimization is enough? Go to ../optimize-workload/SKILL.md.
• The missing piece is training an RLM policy from local privileged trajectories? Go to ../recursive-language-model/references/pedagogical-training.md first; this handoff is only for work that still needs external or hosted training. A local weight-update rung — ../local-distillation-lab/SKILL.md — should be ruled out first when failure attribution says it could solve the residual; do not require a weak local experiment when the evidence already shows the missing capability needs hosted scale or a stronger trainer.
• Before continuing, confirm RL would not be wasted spend: (a) attribute the multi-turn rollouts and confirm the residual is cross-turn reasoning, not format or argument-value (cheaper rungs fix those); (b) the reward is dense, not strict — a binary/strict reward can be constant within a group, giving zero advantage and no gradient; and (c) the chosen model has a first-class multi-turn GRPO trainer and renderer (e.g. NVIDIA Nemotron-3 does; Google Gemma-4 does not yet — no merged trainer, no multi-turn renderer). If any gate fails, fix it (or pick a supported model) before any RL handoff. For (b), implement the rewardability check per references/rewardability.md against the real scored-rollout artifact; for (c), use the model matrix in references/rl-readiness-matrix.md.
• Only continue once the confirmed need is RL / stateful policy training that the local rungs cannot satisfy. Record the confirmed need in .understudy/verifier-handoff/handoff.json (see Handoff Packet) — the later stages refuse to run without it.