Menu
Use when the user asks to enable, disable, or inspect future-session routing guidance; configuration only, not current-turn workflow selection.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | auto-routing |
| description | Use when the user asks to enable, disable, or inspect future-session routing guidance; configuration only, not current-turn workflow selection. |
| argument-hint | [on|off|status] |
This generated file is the Codex-facing runtime skill document. Codex should read this file directly; maintainers edit the source documents listed below instead.
Source order:
../../docs/skill-core/auto-routing.md../../docs/platforms/codex-child-packet-floor.md../../docs/platforms/codex-runtime.md../../docs/platforms/codex-auto-routing.mdThe sections below are already composed for this platform. Do not ask the runtime model to load another platform's runtime document or invocation syntax.
Every platform bootstrap always carries compact native skill-loading guidance plus the always-on SessionStart no-route and direct-edit boundary; native skill descriptions own positive destination selection. Auto Routing controls whether Claude Code SessionStart adds the stronger forced-routing layer. The toggle only adds or removes that opt-in layer; it does not change the baseline lanes on any platform or add hidden runtime routing.
Auto Routing is a workflow-entry configuration stage, not a software development stage.
Use it to configure future-session routing guidance. It should not gather requirements, plan, edit code, debug failures, clean code, or verify completion.
Use when the user asks to:
Do not use as a substitute for skill selection inside the current session — apply the always-on SessionStart boundary and native workflow skill descriptions for current-turn workflow selection.
Apply the active platform runtime document before changing settings. Some platforms support persistent bootstrap routing; others can only explain the setting and leave runtime behavior unchanged.
The setting is stored outside the plugin cache so updates do not overwrite it.
Preferred location when the active platform provides plugin data:
<platform-plugin-data>/config.json
The bundled scripts/oh-no-config script resolves the data directory; the
platform runtime document names the plugin root.
Fallback location when no platform plugin-data directory exists:
${XDG_CONFIG_HOME:-$HOME/.config}/oh-no-harness/config.json
Stored shape:
{
"autoRouting": {
"enabled": true
}
}
When Bash is available, use the bundled script instead of editing config by hand.
When the active platform runtime document exposes the plugin root:
"<plugin-root>/scripts/oh-no-config" status
"<plugin-root>/scripts/oh-no-config" on
"<plugin-root>/scripts/oh-no-config" off
If the plugin root is not exposed, resolve the installed script with the active platform runtime document's script-locator.
on or off, persist the preference, report the config path, and report its semantics according to the active platform adapter.status, report whether auto-routing is on or off and where the setting is stored.This compact main-session source is the hook-disabled native-skill fallback for caller-owned child packets. When SessionStart is enabled, its compatible global floor remains the normal direct-dispatch owner.
The main caller sends each child a proportional self-contained English packet with purpose/outcome; target role; exact target/revision and result/revision binding for repository mutation, review, or verification; scope/permissions/non-goals; contract/acceptance; expected evidence/output; and stop/escalation. Keep simple read-only packets proportional. Workflow-specific IDs and deltas come from the selected skill; role prompts do not reconstruct omitted caller context.
For initial independent review, verification, or debugging, withhold maker conclusions, expected verdicts, sibling outputs, and preferred root-cause hypotheses. Disclose them only later when needed for audit or clarification.
This compact platform section is embedded in generated Codex-facing skill documents.
Codex-facing public skills live under skills/. Generated
skills/<skill>/SKILL.md files compose the matching skill core, this compact
runtime section, and any Codex skill-specific overlay such as
docs/platforms/codex-<skill>.md.
Ask approval, preference, scope, or next-step questions directly in the Codex conversation. Keep prompts outcome-first: state the desired outcome, acceptance criteria, non-goals or side effects, expected evidence, and output shape before detailed steps.
Use compact final answers unless the active skill requires a plan, review, or verification report. Preserve durable state in written artifacts before long work, compaction, or handoff.
Dispatch only after the active skill's trigger fires, then read
docs/platforms/codex.md ## Role Dispatch for the full host contract. Use
spawn_agent(task_name="ralplan_planner_draft_01", agent_type="oh-no-planner", message=<self-contained packet>, fork_turns="none") first; the legacy spawn_agent(agent_type="oh-no-planner", ...) shorthand is incomplete
(omitting fork_turns="none" defaults to a full-history fork, which rejects a custom
agent_type), do not combine it with fork_context=true, and use generic
prompt embedding only after the custom agent is actually rejected. The example encodes the Ralplan workflow, Planner role, draft phase, and stable ordinal; derive each caller's concrete identity the same way and keep sibling names unique. The task packet carries scope, ownership, expected
output, and lifecycle; task names match ^[a-z0-9_]+$, use deterministic workflow/role/phase-or-lens/stable-ordinal sibling uniqueness, and never replace requested agent_type plus child agent_role and matching developer instructions as role proof.
Every dispatched result is a dependency: wait_agent must reach final status,
the caller captures and uses the output, and only then performs lifecycle
cleanup. Timeout, empty output, or "No agents completed yet" is not final; do
not close, redo inline, or use missing output as evidence.
After confirmed custom-agent unavailability, embed
docs/agent-core/<role>.md; see the full platform doc for the fallback shape.
This channel is trigger-loaded, not embedded in every workflow decision. When a
named THOROUGH paired-review or Fusion Rescue trigger fires, read and apply
docs/platforms/codex.md ## Cross-Host Consult Channel before dispatch. Until
then, do not preload opposite-host invocation details.
This platform overlay is source content for the generated Codex-facing
auto-routing runtime document, after the shared core and
docs/platforms/codex-runtime.md.
Codex native skill loading remains the primary routing surface, with skill
descriptions providing destination discovery. Hooks are opt-in, and the
auto-routing skill stores and explains the preference, but enabling it
does not add forced routing and does not change current routing semantics.
If a Codex-facing SessionStart hook runs, it must stay compact and must not embed full skill core bodies.
Resolve the installed config script before running status, on, or off:
tab="$(printf '\t')"
cache="${CODEX_HOME:-$HOME/.codex}/plugins/cache"
# Codex exposes no skill-visible plugin root, so cache-newest is the only reachable
# path. Sort on the VERSION path component (full path only as tie-break) so a second
# marketplace identity cannot let an older version win.
script="$(find "$cache" -path '*/oh-no-harness/*/scripts/oh-no-config' 2>/dev/null \
| awk -F/ '{for(i=NF;i>0;i--) if($i=="scripts"){print $(i-1)"\t"$0; break}}' \
| LC_ALL=C sort -t"$tab" -k1,1V -k2,2 | tail -n1 | cut -f2-)"
"$script" status
Use when the user explicitly delegates autonomous end-to-end delivery across discovery, planning, implementation, and verification; not for a small execution-ready task.
Use when the user explicitly delegates autonomous end-to-end delivery across discovery, planning, implementation, and verification; not for a small execution-ready task.
Use when requirements are sufficiently known but implementation is broad, risky, architecture-sensitive, cross-file, multi-step, or strategy-unclear and needs a plan; not for still-vague discovery or an execution-ready task.
Use when the user explicitly requests TDD, test-first, or RED-GREEN-REFACTOR, or an already-selected workflow enters its internal TDD gate; ordinary implementation remains Ralph.
Use when requirements are sufficiently known but implementation is broad, risky, architecture-sensitive, cross-file, multi-step, or strategy-unclear and needs a plan; not for still-vague discovery or an execution-ready task.
Use when the user explicitly requests TDD, test-first, or RED-GREEN-REFACTOR, or an already-selected workflow enters its internal TDD gate; ordinary implementation remains Ralph.