Map authorized work into the minimum viable execution shape. Only choose the execution method; do not create permissions, task trackers, specifications, or new workflows.
Harness binding
Generic routing uses only tier and purpose. Each tier/purpose maps to one role code shared across harnesses:
| Tier/purpose | Role code |
|---|---|
light |
light_worker |
standard |
standard_builder |
frontier |
Lead (main session) |
expert |
expert |
| fresh review | reviewer |
| direction reanalysis | reanalyst |
Complete generic routing first, then read the binding:
- Harness binding reference table: the model and effort for each role code in each harness is the sole source of the actual model.
- The current harness's profile: configuration location, binding method, fresh context, read-only evidence, and degradation rules.
- Codex：profiles/codex.md
- Claude Code：profiles/claude-code.md
- No verified profile: keep the abstract tier, have the main Agent use capabilities that can be proven on site, and record the binding deviation; do not guess the model, effort, read-only, or fresh-context capabilities.
The runtime profile can only select the actual model and role; it cannot change mode, risk, shape, approval, or project rules. The main session's model and effort are chosen by the user; the Router only reads them back and does not automatically switch to match the profile.
Project configuration gate
When applying this Skill, first confirm the project-level Agent configuration and runtime metadata according to the current harness profile. Only check the roles needed for this routing; if required configuration is missing and the runtime cannot provide equivalent capabilities allowed by the profile, read that harness's configuration guidance, explain the degraded capabilities that can currently be used safely, and then ask the user whether to "create the recommended configuration," "only show the recommendation," or "do not configure for now":
Before the user's choice is obtained, configuration must not be created or modified. If the user skips it, generic routing can still be completed, but the abstract tier must be retained, only capabilities provable on site may be used, and binding deviations must be recorded; unverified named roles, models, effort, read-only, or fresh-context capabilities must not be written as already available.
Confirm boundaries first
- Read system, user, and project rules first. Higher-level rules always take precedence.
- Confirm that the goal, allowed scope, acceptance method, and stop conditions are sufficient for execution.
- If missing information would change the result, permissions, or risk, ask first or conduct a limited read-only investigation.
- Follow the project's existing task tracker, Git, security, and approval rules; do not create a second system.
- Only use Agents, sandboxes, review, and concurrency capabilities whose existence can be proven by the execution environment; do not guess based on names.
Dispatch, retry, or escalation may only change the executor; they must not expand files, tools, external mutation, or approval scope.
Routing order
Decide in order mode → tier → risk → shape → review → fallback. Risk controls approval and review; it does not directly determine the number of Agents.
1. Choose mode
| Mode | Condition | Next step |
|---|---|---|
execute |
Result, scope, and acceptance are clear | Execute directly, or hand off to the lowest capable tier |
explore_then_plan |
Direction is clear, but evidence is insufficient, cross-component, or recovery is expensive | Do a limited read-only investigation to form one verifiable work slice |
co_discover |
The problem, product choices, or acceptance criteria are still unclear | Clarify only the questions that would change direction, along with low-cost probing |
2. Choose the tier
| Tier | Work characteristics |
|---|---|
light |
Mechanical work such as searching, enumerating, reproducing, testing, and formatting with fixed rules |
standard |
Implementation, debugging, integration, and review with clear boundaries but requiring engineering judgment |
frontier |
Ambiguity, architecture, cross-component root causes, security, irreversible decisions, and final arbitration |
expert |
Complex cross-layer problems, or cases requiring independent re-investigation across multiple rounds of wrong assumptions and contradictory evidence |
Choose the lowest capable tier. A higher tier may temporarily stand in for a lower tier, but the model binding deviation must be noted alongside the routing record; a lower tier must not replace necessary security, architecture, or high-risk judgment. The actual model and effort are bound by the execution environment settings, and this Skill does not specify product model names.
3. Apply the risk gate
| Risk | Typical conditions | Minimum verification |
|---|---|---|
low |
Local, recoverable, with direct acceptance | Self-tested by the executor, rechecked by the main Agent |
material |
Cross-file or cross-component, or changes user-visible behavior | Integrated verification by the main Agent; use a fresh-context review when there is significant uncertainty |
high |
Security, release, external state, or expensive recovery | Explicit plan and approval gate; use a fresh-context review after completion |
critical |
Data loss, production traffic, irreversible impact, or significant privilege impact | Stop automated execution, obtain explicit approval and independent verification |
If the work involves a database or production environment mutation, first use explore_then_plan / frontier / critical.
Approval only authorizes the specified operation; it does not equal completion verification.
4. Pass the dispatch brake
Confirm each item before dispatching:
- The completion result of each work agent can be stated clearly in one sentence.
- Having the main Agent do it directly would not be cheaper and more reliable.
- The work does not need to wait for another work agent to proceed.
- Each writable artifact has only one owner.
- The owner responsible for integration and final verification has been designated.
If any item does not hold, keep direct, or investigate first until the boundaries are clear. Once passed, use only three shapes:
| Shape | Conditions |
|---|---|
direct |
Small work, tightly coupled problems, or direction still requiring the main Agent's judgment |
single_worker |
One independent workflow with clear boundaries and acceptance criteria |
bounded_parallel |
At least two ready work items that are independent of each other and have non-overlapping write responsibilities |
When using single_worker or bounded_parallel , the dispatch instructions must at least include: objective, allowed write scope,
untouchable scope, input evidence, acceptance command, stop conditions, and return format. The main Agent retains integration responsibility.
5. Choose review and fallback
low: usereview=lead, and do not create reviewers for formality's sake.material: by default, integrated verification is done by the main Agent; for cross-module work, high uncertainty, or obvious author bias, usereview=fresh。high / critical: completion claims usereview=approval+fresh. If the execution environment cannot prove fresh context or read-only capability, stop the completion claim and do not pass off self-review as the real thing.- For general execution failures, first fix the dispatch instructions, evidence, or environment issues; when needed, retry at most once at the same tier.
- If it fails again for the same reason, escalate at most one tier. If it still fails after escalation, or a required capability is unavailable, hand it back to the main Agent or the user, and do not automatically rerun.
Three rounds of misjudged direction on the same problem
A misjudged direction is when the original root-cause judgment or correction direction is overturned by subsequently verifiable evidence. Each round records the "original judgment, counter-evidence, result"; multiple failed assertions in the same round count only once. General test failures, expected RED, command errors, and insufficient network or permissions do not count; only if they otherwise provide evidence overturning the original judgment do they count as one misjudged direction for that round.
The same unresolved problem accumulates across main/sub-agents; switching agents, switching methods, or interleaving other work does not reset it; different problems that have been resolved are not counted together. Use existing task records to preserve the count and evidence; do not add a new counting program or tracking system.
When the cumulative total reaches three rounds and the main model meetsthe main model conditions in the comparison table,
stop implementing the same problem, set fallback=direction-reanalysis-once, and dispatch a completely new context
reanalyst to reanalyze.
Deliver only the original goal, authorization boundaries, fixed version, and the three rounds of original judgments and counter-evidence; do not treat the previous agent's conclusions as established facts.
The reanalysis reads only the originally authorized data, and returns erroneous assumptions, evidence, recommended correction directions, and remaining unknowns; it does not implement,
does not change task status, and does not resume paused work on its own. Start it at most once for the same problem, and the main session verifies the result; if it is still unresolved
or diagnostic capability is unavailable, hand it back to the user, do not dispatch a second diagnostic agent, and do not downgrade or pretend otherwise.
This is an independent reanalysis; it does not increase the general retry quota, nor does it require deliberately trying three times. Existing approvals and safety stop conditions take effect immediately; if they prohibit continuing the investigation, only record the reason pending analysis and do not start an agent.
Output route receipt
For non-simple dispatch, capability escalation, or high-risk direct execution, output one line:
mode=execute risk=material tier=standard shape=single_worker owner=builder review=fresh fallback=one-tier-max
Fields use only the following values:
| Field | Value |
|---|---|
mode |
execute、explore_then_plan、co_discover |
risk |
low、material、high、critical |
tier |
light、standard、frontier、expert |
shape |
direct、single_worker、bounded_parallel |
owner |
Name of the role or Agent responsible for delivery |
review |
lead、fresh、approval+fresh |
fallback |
none、same-tier-once、one-tier-max、direction-reanalysis-once |
The route receipt only preserves the decision; it does not replace dispatch instructions, test evidence, approval records, or task status. Simple and directly completed work does not need to output a route receipt for the sake of format.
If the runtime profile requires a binding receipt, place it on the line below the route receipt. The binding receipt may only supplement the actual role, model, effort, and deviations; it must not overwrite the general routing result.
Fixed regression cases
| Case | Expected route |
|---|---|
| Answer a single fact or read-only confirmation | execute / light / low / direct / lead |
| A single engineering change 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 |
| Requirements and acceptance still have product ambiguity | co_discover / frontier / direct |
| Cross-component, insufficient evidence but clear direction | explore_then_plan / frontier / material / direct |
| Complex cross-layer, with independently deliverable subtopics | explore_then_plan / expert / material / single_worker / lead; model depends on profile |
| Main model matching the profile, with three cumulative rounds of misjudged direction on the same problem | Stop implementing the same problem; a completely new context performs one read-only reanalysis, reusing the original risk and approval boundaries |
| Database or production environment mutation | explore_then_plan / frontier / critical / approval+fresh |
| Lower capability tier unavailable | After recording the binding deviation, escalate one tier, or have the main Agent handle it directly |
| The required fresh-context reviewer is unavailable | Stop high-risk completion claims; do not pass off self-review as such |
Changing the execution environment settings may only change the actual model; it must not change mode, risk, shape, or safety boundaries.
Stop conditions
Stop automatic progression when any of the following occurs:
- Authorization, scope, or acceptance will still change the routing result.
- The required approval has not yet been obtained.
- The execution environment cannot prove the necessary capability.
- After dispatch, unexpected overlapping writes or external state changes occur.
- The same cause has already used one same-tier retry and one tier escalation: stop implementation; only one re-analysis that meets the previous section and is still authorized may proceed separately, and it cannot be used to regain implementation or retry allowance.
Do not create a scheduler, queue, Agent registry, Hook, routing database, or general task tracker. Only when real failure evidence shows that the Prompt and the execution environment's native capabilities are insufficient should a program or Hook be evaluated as a separate case.