Governed Delegation

Canonical model-routing source: docs/MODEL_ROUTING_POLICY.md
If this file conflicts with routing doctrine, the canonical policy doc wins.

Use this skill when a task may require subagents or governed delegation.

This is the canonical front door for delegation-envelope policy in configuration/governance work.
Use it to answer one narrow question well:

If delegation is needed, what execution envelope is allowed?

Do not use this skill as a substitute for:

• - live runtime inspection
• persisted config inspection
• config mutation/apply workflows

Goal

Keep the split clean:

• - GPT decides whether delegation is needed, how to decompose the work, and whether deterministic execution is better
• governed delegation decides the allowed execution envelope
• OpenClaw runtime performs the actual spawn/execution through supported surfaces

Do not patch OpenClaw core for this.
Do not depend on dist internals.
Prefer add-on boundaries.

Default rule

Before delegating, classify the task on four axes:

• - taskClass: INLINECODE2
• INLINECODE3: INLINECODE4
• INLINECODE5: INLINECODE6
• INLINECODE7: INLINECODE8

Then use the helper:

• - INLINECODE9

For Class C/D or other fail-closed work, include frontDoor explicitly (for example orchestrator:orchestrators/reflect/orchestrator.md). The helper now rejects strict requests when the requested front door does not match canonical policy.

Policy intent

• - GPT for ambiguity, policy interpretation, arbitration, deep synthesis, and critical governance review
• CODEX for bounded implementation, deterministic transforms, verification, backup/apply/validate routines
• MINIMAX only for bounded low-risk read-only work
• fail closed for Class C/D and other unsafe downgrade cases

When to use

Use this skill when:

• - an orchestrator needs subagents
• a cron/delegated task needs model-tier guardrails
• a task mixes planning and implementation and you need a safe split
• a critical write or durable memory/governance task must not silently degrade to a weak model

Use it after deciding that delegation is actually on the table.
For ordinary questions like "what is live right now?", "what does the saved config say?", or "apply this config change safely", start with the appropriate inspection/mutation surface instead.

Output contract

The helper should produce a decision containing:

• - chosen model
• failClosed true/false
• policy source
• runner type
• optional auditable spawn request envelope

Minimal workflow

1. 1. Decide if delegation is actually needed
2. Classify task risk/type
3. Ask governed-delegation helper for decision
4. If safe, pass the resulting request to the supported runtime/tool surface
5. If not safe, refuse or escalate instead of degrading

Canonical config/governance split

• - live runtime state → inspect runtime/session/gateway state directly
• saved config state → inspect persisted config/schema directly
• safe mutation → use supported config patch/apply/restart flows
• delegation policy → use this skill

If plain GPT or a direct deterministic runner is enough, do not add delegation. This skill reduces unsafe delegation — it is not a reason to turn everything into a subagent workflow.