Relay

Relay

Route the user's task through the coding environment's native child tasks or agents, chosen by role rather than model family:

1. a frontier planner resolves ambiguity and defines the finish line;
2. a cheaper, faster workhorse executor implements the settled plan;
3. a separate frontier reviewer independently checks the result.

The user may supply any model map, for example:

planning: Fable
execution: GPT-5.5
review: GPT-5.6 Sol
save: project

Model names are configuration, never capability claims. The coordinator discovers what the active environment can actually delegate to, classifies those models from current evidence, suggests the route, verifies every handoff, and reports the route actually used.

Run the relay only when the user explicitly invokes it or explicitly requests this delegation pattern. Automatic skill loading is not authorization to create child work. Explicit invocation authorizes the native child tasks required by the route, including model and effort selection. It does not authorize destructive actions, external mutations, or deployment unless the user separately authorized them.

Preflight

1. Restate the requested outcome, acceptance criteria, constraints, allowed mutations, and deployment authority.
2. Read ENVIRONMENTS.md completely. Select the matching adapter and record whether the environment can discover child-selectable models, select a model, verify the actual model used, inspect results, and continue a child. If a required control is absent, report the precise limitation; do not imitate it with hidden subprocesses or direct provider calls.
3. Record the starting state. In a Git repository, capture the branch, revision, and dirty files so relay work remains distinguishable from pre-existing changes.
4. Classify the work:
   • Settled: the solution and finish line are already known; planning may stay in the coordinator.
   • Judgment-heavy: implementation is tractable, but tradeoffs or failure modes need a planner.
   • Open-ended: the problem, architecture, or safe path must be discovered before execution.
5. Read PREFERENCES.md completely. Load user and project preferences from its defined paths when present. Treat saved selectors as preferences, never as availability or tier evidence.
6. Read MODEL_SELECTION.md completely. Use its discovery procedure to produce an evidence-backed inventory of every model selectable for child work, then classify each as frontier, workhorse, utility, or unknown. Availability discovery is complete only when every candidate has a native selector and evidence from the active environment—not merely a provider catalog, saved preference, or remembered model name.
7. Choose each phase using this precedence: an explicit choice for the current run, then a valid saved project preference, then a valid saved user preference, then automatic suggestion. Validate every selected model against the current inventory and phase gate before routing.

| Role | Model | Effort | Why this model fits | Substitution |
| --- | --- | --- | --- | --- |
| Planning | <frontier model> | <effort> | <uncertainty it must resolve> | <allowed fallback or stop> |
| Execution | <workhorse model> | <effort> | <bounded work it can complete> | <allowed fallback or stop> |
| Review | <independent frontier model> | <effort> | <risks it must inspect independently> | <allowed fallback or stop> |

Show the inventory, classification confidence, and suggested map before launching children. Explicit invocation authorizes the skill to proceed with high-confidence selections. Pause when a required role has no qualifying model, a classification is low-confidence, or the suggestion conflicts with an explicit user choice.

When the user asks to save or update preferred models, follow PREFERENCES.md. Persistence is a separate file mutation: never infer permission to save from a one-run model choice. Report the saved scope and path after writing, and show which preferences were applied or bypassed during preflight.

Use exact model IDs or documented native selectors and effort values exposed by the host. Never invent an identifier or silently substitute a model. Preflight passes when the finish line is checkable, every external side effect is authorized, and the planner and reviewer are genuine frontier models—not merely the strongest models in a weak inventory.

Build the route

Create the shortest route that preserves independent review:

| Phase | Child | Model | Effort | Deliverable | Gate |
| --- | --- | --- | --- | --- | --- |
| Planning | ... | ... | ... | settled plan | affected surfaces, decisions, risks, checks, integration path |
| Execution | ... | ... | ... | implementation artifact | requested behavior exists and focused checks pass |
| Review | ... | ... | ... | independent findings | every finding is resolved or rejected with evidence |

• Keep planning in the coordinator only when its verified model is frontier; otherwise create a frontier planning child even when the task appears settled.
• Give execution to the cheapest, fastest available workhorse that can reliably meet the gate. Promote execution to a frontier model when no workhorse satisfies the task's risk or capability requirements.
• Use a fresh reviewer thread with no executor context beyond the task, plan, actual artifact, and evidence. The reviewer must not review its own work.
• Prefer a reviewer with a different model ID and family from both executor and planner. If only one frontier model is available, use it in a fresh review context and disclose the reduced model diversity.
• Add reconnaissance, integration, release, or monitoring phases only when they produce a necessary artifact or reduce material uncertainty.
• Parallelize only independent slices with disjoint ownership or an explicit integration seam. Permit only one writing thread per checkout.

If deployment is in scope, read DEPLOYMENT.md completely before assigning the release phase. The route passes when every phase has one owner, one artifact, and one checkable gate, and no dependent phase starts before its inputs exist.