Skill Router
Use this skill to make Codex routing environment-aware instead of guess-based.
Quick Start
- Classify the task into a lane:
-direct
-broken
-build
-operate
-review
-plan - Run
scripts/scan_codex_inventory.pyto inspect local skills, plugins, and MCP servers. - Match the task against the most specific local capability first.
- Return a compact recommendation using the routing contract in
references/routing-contract.md.
Lane Selection
| Lane | Examples | Default Reasoning | Default Thinking |
|---|---|---|---|
direct |
trivial read, one command, factual answer | fast | none |
broken |
bug, regression, crash, failing test, broken build | standard | think |
build |
new feature, component, integration, workflow | standard | think |
operate |
refactor, automate, configure, document, deploy | standard | none |
review |
code review, risk review, security review | standard | think-hard |
plan |
broad, ambiguous, multi-stage, scope decisions | frontier | ultrathink |
Escalate to frontier reasoning + ultrathink for: production incidents,
auth/permissions changes, architecture decisions where rollback is expensive.
If a task spans multiple lanes, choose the first critical lane and note the downstream chain.
Capability Resolution
Prefer, in order:
- repo instructions already in force
- local Codex skills
- enabled plugins
- configured MCP/tool surfaces
- direct execution
Rules:
- prefer one strong local capability over a long chain
- prefer the most specific capability over the most famous one
- fall back to direct execution if no strong local match exists
- do not search the internet for skills by default
- do not auto-install anything silently
Inventory Scan
Use the bundled script:
python3 scripts/scan_codex_inventory.py
python3 scripts/scan_codex_inventory.py --query deploy
python3 scripts/scan_codex_inventory.py --json
Use the inventory scan when:
- you need to know which local capability is actually present
- multiple possible skills might match
- the task mentions a tool or platform and you want to confirm availability
Output Contract
Always return:
- lane
- chosen capability or fallback
- reasoning tier:
fast,standard, orfrontier - verification plan
- short notes only if needed
See references/routing-contract.md for the canonical shape.
Named Chains (Optional)
If AGENTS.md declares saved chain sequences, check them BEFORE computing
fresh from the lane tables. Match by substring on the user's prompt; first
match wins.
# in AGENTS.md
chains:
- name: ship-feature
when: ["ship the feature", "lets implement"]
chain: writing-plans → frontend + db
thinking: think
Per-step models / agents resolve from the lane tables unless chain.model
or chain.thinking overrides globally, or steps[].model overrides per
step.
Dispatch Protocol — Per-Step Model Enforcement
When a chain step needs a different model than the parent session, dispatch
that step as a Codex sub-task with model: set explicitly. Steps that
match the parent model run inline.
For each step in the chain:
IF step.model == parent_model AND not parallel-fan-out:
→ run inline
ELSE:
→ spawn sub-task with model=<step.model>, agent=<step.agent>
Parallel steps (`+`) launch concurrently.
Thinking Depth
Each lane row carries an optional Thinking value: none / think /
think-hard / ultrathink. Pre-pend the keyword to the dispatch prompt to
allocate extended-thinking budget. Production incidents and architecture
decisions default to ultrathink; mechanical work to none.
Codex-Specific Notes
- this skill is local-first
- this skill is for routing and orchestration, not governance
- for enterprise governance, policy, and proof of judgment, use Sentigent instead of expanding this skill into a control plane
Resources
scripts/
scan_codex_inventory.py: inspect installed local Codex skills, enabled plugins, and configured MCP servers
references/
routing-contract.md: required output shape for recommendationsproduct-boundary.md: product boundary and audience definition for the Codex version
