Custom Agent Router
Map authorized tasks into the minimal viable execution shape. Only select execution methods; do not create permissions, task trackers, specifications, or new workflows.
Bind Execution Environment
Complete the general routing first, then read the current runtime profile:
- Codex: Read Codex runtime profile.
- No validated profile: Retain the abstract tier, use field-verifiable capabilities by the main Agent, and record binding deviations; do not guess model, effort, read-only, or fresh-context capabilities.
The runtime profile can only select actual models and roles, and cannot modify mode, risk, shape, approval, or project rules.
Codex Project Configuration Gate
When applying this Skill in Codex runtime, first check the current project's
,
, and runtime metadata. If the project configuration does not exist, is incomplete, or cannot be proven to comply with the profile, read
Codex Project Onboarding Guide, explain the currently available downgraded capabilities that can be used safely, then ask the user to choose "Create recommended configuration", "Show only recommendations", or "Skip configuration for now".
Do not create or modify configurations without obtaining the user's selection. If the user skips, the general routing can still be completed, but the abstract tier must be retained, only field-verifiable capabilities can be used, binding deviations must be recorded, and unvalidated named roles, models, effort, read-only, or fresh-context capabilities cannot be written as available.
Confirm Boundaries First
- First read system, user, and project rules. Upper-level rules always take precedence.
- Confirm that objectives, allowed scopes, acceptance methods, and stop conditions are sufficient for execution.
- If missing information will change the result, permission, or risk, first ask questions or conduct limited read-only investigations.
- Follow the project's existing task trackers, Git, security, and approval rules; do not establish a second system.
- Only use Agents, sandboxes, review, and parallel processing capabilities that can be proven to exist in the execution environment; do not guess based on names.
Dispatch, retry, or upgrade can only change the executor, and cannot expand the scope of files, tools, external mutations, or approvals.
Routing Sequence
Determine
mode → tier → risk → shape → review → fallback
in order. Risk controls approval and review, and does not directly determine the number of Agents.
1. Select Mode
| Mode | Conditions | Next Step |
|---|
| Clear results, scope, and acceptance criteria | Execute directly, or assign to the minimally competent capability tier |
| Clear direction, but insufficient evidence, cross-component, or high recovery cost | Conduct limited read-only investigation to form a verifiable task slice |
| Unclear problem, product selection, or acceptance criteria | Only clarify issues that will change the direction, paired with low-cost exploration |
2. Select Tier
| Tier | Task Characteristics |
|---|
| Search, enumeration, reproduction, testing, formatting, and mechanical tasks with fixed rules |
| Implementation, debugging, integration, and review tasks with clear boundaries that require engineering judgment |
| Ambiguity, architecture, cross-component root cause analysis, security, irreversible decisions, and final arbitration |
Select the minimally competent tier. Higher tiers can temporarily replace lower tiers, but model binding deviations must be noted next to the routing record; lower tiers cannot replace necessary security, architecture, or high-risk judgment. The actual model and effort are bound by the execution environment settings; this Skill does not specify product model names.
3. Apply Risk Gate
| Risk | Typical Conditions | Minimum Verification |
|---|
| Local, recoverable, direct acceptance | Self-test by executor, review by main Agent |
| Cross-file or cross-component, or changes user-visible behavior | Integrated verification by main Agent; use fresh-context review when there is obvious uncertainty |
| Security, release, external state, or high recovery cost | Clear plan and approval gate; use fresh-context review after completion |
| Data loss, production traffic, irreversible, or major permission impact | Stop automatic execution, obtain explicit approval and independent verification |
If the task involves database or production environment mutation, first use
explore_then_plan / frontier / critical
. Approval only authorizes specified operations, and does not equal completion of verification.
4. Pass Dispatch Brake
Confirm the following items one by one before dispatch:
- The completion result of each task agent can be clearly described in one sentence.
- Direct execution by the main Agent is not cheaper or more reliable.
- The task does not need to wait for another task agent to proceed.
- Each writable artifact has only one responsible party.
- The responsible party for integration and final verification has been designated.
If any item is not satisfied, maintain
, or first investigate until the boundaries are clear. After passing, only use three shapes:
| Shape | Conditions |
|---|
| Small tasks, tightly coupled problems, or direction still requires judgment by the main Agent |
| An independent workflow with clear boundaries and acceptance criteria |
| At least two ready tasks that are independent of each other and have non-overlapping writing responsibilities |
When using
or
, the dispatch description must include at least: objective, allowed writing scope, forbidden scope, input evidence, acceptance command, stop condition, and return format. The main Agent retains integration responsibility.
5. Select Review and Fallback
- : Use , do not establish reviewers for formality.
- : Default to integrated verification by the main Agent; use when cross-module, high uncertainty, or obvious author bias exists.
- : Use for completion declaration. If the execution environment cannot prove fresh-context or read-only capabilities, stop the completion declaration and do not pretend to be self-review.
- For the first failure, first correct the dispatch description, evidence, or environment issues; retry at most once in the same tier if needed.
- If it fails again for the same reason, upgrade at most one tier. If it still fails after upgrading, or necessary capabilities are unavailable, hand it back to the main Agent or user, and do not automatically rerun.
Output Routing Record
Output one line for non-trivial dispatch, capability upgrade, or high-risk direct execution:
text
mode=execute risk=material tier=standard shape=single_worker owner=builder review=fresh fallback=one-tier-max
Only use the following values for fields:
| Field | Values |
|---|
| , , |
| , , , |
| , , |
| , , |
| Role or Agent name responsible for delivery |
| , , |
| , , |
The routing record only saves decisions, and does not replace dispatch descriptions, test evidence, approval records, or task status. Simple and directly completed tasks do not need to output routing records for formatting purposes.
If the runtime profile requires a binding receipt, place it on the line below the route receipt. The binding receipt can only supplement actual roles, models, effort, and deviations, and cannot overwrite the general routing result.
Fixed Regression Cases
| Case | Expected Routing |
|---|
| Answer a single fact or read-only confirmation | execute / light / low / direct / lead
|
| Single engineering modification with clear boundaries | execute / standard / material / single_worker / lead
|
| Two independent inventories that do not write to the same file | execute / light / low / bounded_parallel / lead
|
| Product ambiguity in requirements and acceptance | co_discover / frontier / direct
|
| Cross-component, insufficient evidence but clear direction | explore_then_plan / frontier / material / direct
|
| Database or production environment mutation | explore_then_plan / frontier / critical / approval+fresh
|
| Low-capability tier unavailable | Record binding deviation then upgrade one tier, or handle directly by main Agent |
| Necessary fresh-context reviewer unavailable | Stop high-risk completion declaration, do not pretend to be self-review |
Changing execution environment settings can only modify the actual model, and cannot change mode, risk, shape, or security boundaries.
Stop Conditions
Stop automatic advancement when any of the following situations occur:
- Authorization, scope, or acceptance criteria will still change the routing result.
- Required approval has not been obtained.
- The execution environment cannot prove necessary capabilities.
- Unexpected overlapping writes or external state changes occur after dispatch.
- One same-tier retry and one tier upgrade have been used up for the same reason.
Do not create schedulers, queues, Agent registries, Hooks, routing databases, or general task trackers. Only evaluate programs or Hooks separately when real failure evidence shows that Prompt and native execution environment capabilities are insufficient.