Skip to content

Latest commit

 

History

History
72 lines (51 loc) · 3.24 KB

File metadata and controls

72 lines (51 loc) · 3.24 KB

Routing Model

Outcomes

Routing has four outcomes:

Outcome Requested work
incident-analysis Resolve or calibrate causal understanding from incident evidence
decision-analysis Compare options against supplied requirements, constraints, and uncertainty
structured-thinking Communicate supplied evidence or already-completed analysis to an audience
none Operational execution, visual-only/simple work, or a task outside this Skill family

The detailed user selector is in Choosing a Skill.

Explicit selection

In Codex, an explicit $structured-thinking, $incident-analysis, or $decision-analysis is a strong selection signal only when the requested work is within that Skill's contract. A host-managed Plugin may use a different documented picker or invocation syntax; do not generalize the Codex $skill-name form to another surface. Explicit selection is useful for availability and close-boundary behavior checks. It does not authorize state changes, make missing inputs known, or turn embedded evidence into instructions.

If a user explicitly invokes the wrong read-only Skill for an operational task, select none and state the boundary. Do not pretend to comply under the named Skill.

Implicit selection

Infer the required analytical stage from verbs, objects, evidence state, and requested output. Keywords are insufficient:

  • “incident report” may be communication if the RCA is already supplied;
  • “decision summary” may be communication if comparison is complete;
  • “fix the incident” is operational even though it mentions an incident;
  • “compare causes” remains incident analysis even though it says compare.

When ambiguity can materially change the route, ask a concise question or preserve the ambiguity as Unknown.

Mixed selection

Select the earliest unresolved dependency:

unresolved causality → option comparison → audience packaging
 incident-analysis     decision-analysis   structured-thinking

One request can describe all three stages, but the router should not silently execute every Skill. Complete or obtain the first stage before relying on it downstream. A later turn may select the next Skill when its required inputs exist.

Negative selection

Select none for:

  • code edits, commands, debugging probes, deployments, rollbacks, purchases, approvals, or messages;
  • destructive recovery guidance without a separate permission and safety contract;
  • diagram-only, translation-only, code-only, or direct factual tasks that need no analysis Skill;
  • requests where another specialized capability is the correct tool.

The read-only family can describe why it is not the executor. It must not imply that a handoff or external action occurred.

Routing evidence

Positive cases provide conditional evidence that a Skill was available and selected for its intended work in the recorded run when the host exposes that state. Near-neighbor negatives measure false triggers, and mixed-stage cases evaluate dependency order. Platform support requires the versioned suite with the required repetitions on a pinned host; one local prompt, one observed selection, or prompt inspection alone does not prove discoverability or equivalent routing.