Auto - Automatic Routing

Input: $ARGUMENTS

Core Principles

1. The user should never need to know skill names. This skill exists so that any natural-language input gets routed to the correct analytical procedure. The user says what they’re thinking; the system figures out what to do with it.

2. Classification happens BEFORE action. Never start generating a response until you have classified the input. Wrong classification produces structured-but-irrelevant output, which is worse than no structure at all.

3. Misrouting must be survivable. Even if classification is wrong, the sub-orchestrator it routes to contains “Is this actually a [X]?” checks that can reroute. This is defense-in-depth, not an excuse for sloppy classification.

4. When unsure, present interpretations rather than guess. A confident wrong route wastes the user’s time. An honest “I see 2-3 ways to read this” lets the user correct course immediately.

5. The simplest correct route wins. If the input clearly maps to one sub-orchestrator, route there directly. Do not over-analyze clear inputs.

Phase 1: Coarse Classification

Read the input and classify it into exactly ONE of these 5 types:

[A1] RAW_INPUT: [the user's input, quoted]
[A2] COARSE_TYPE: [CLAIM | DECISION | EXPLORATION | EMOTION | ACTION]
[A3] COARSE_EVIDENCE: [which signals from the table matched]
[A4] COARSE_CONFIDENCE: [high | medium | low]

Rerouting Rules (apply in order, first match wins)

These override the initial coarse classification when surface form misleads:

After applying rerouting rules:

[A5] REROUTE_APPLIED: [yes/no — which rule triggered]
[A6] FINAL_COARSE_TYPE: [the type after rerouting]

Phase 2: Fine Routing

Based on the final coarse type, route to the specific sub-orchestrator:

CLAIM routes:

DECISION routes:

EXPLORATION routes:

EMOTION routes:

ACTION routes:

[A7] FINE_ROUTE: /[skill-name]
[A8] FINE_EVIDENCE: [what sub-signal matched]
[A9] FINE_CONFIDENCE: [high | medium | low]

Phase 3: Confidence Check

If COARSE_CONFIDENCE is high AND FINE_CONFIDENCE is high:

Route directly. No further analysis needed.

→ INVOKE: /[skill-name] $ARGUMENTS

If either confidence is medium:

State the route and briefly note the alternative:

[A10] PRIMARY_ROUTE: /[skill-name] — [why this matches]
[A11] ALTERNATIVE_ROUTE: /[alt-skill-name] — [why this might also apply]
[A12] ROUTING_NOTE: [one sentence on why primary was chosen over alternative]

Then route to the primary:

→ INVOKE: /[skill-name] $ARGUMENTS

If either confidence is low:

Present 2-3 interpretations to the user. Do NOT route automatically.

[A10] INTERPRETATION_1: "[restatement of input as Type A]"
  → Would route to: /skill-a
  → This interpretation means: [what the response would address]

[A11] INTERPRETATION_2: "[restatement of input as Type B]"
  → Would route to: /skill-b
  → This interpretation means: [what the response would address]

[A12] INTERPRETATION_3 (if applicable): "[restatement of input as Type C]"
  → Would route to: /skill-c
  → This interpretation means: [what the response would address]

Which interpretation matches what you meant? (Or say more and I'll re-classify.)

Wait for user response. Then re-enter Phase 1 with the clarified input.

Phase 4: Post-Route Verification

After invoking the sub-orchestrator, verify the route was correct by checking:

[A13] OUTPUT_TYPE_MATCH: [does the sub-orchestrator's output type match what the user wanted?]
  - User wanted an answer → did the skill produce an answer (not just a process)?
  - User wanted a decision → did the skill produce a recommendation (not just analysis)?
  - User wanted action → did the skill produce concrete steps (not just exploration)?
  - User wanted emotional support → did the skill acknowledge the feeling (not just analyze it)?

If OUTPUT_TYPE_MATCH is false, note the mismatch for future routing improvement but do NOT interrupt the user’s flow.

Edge Cases

Compound inputs (multiple types in one message)

If the input contains multiple types (“I’m frustrated about X and I need to decide whether to Y”):

1. Identify the DOMINANT type (usually the one stated first or with the most emotional weight)
2. Route to the dominant type’s sub-orchestrator
3. Note the secondary type for the sub-orchestrator to surface after handling the primary

[A14] COMPOUND: yes
[A15] DOMINANT_TYPE: [type] → /[skill]
[A16] SECONDARY_TYPE: [type] — surface after primary is handled

Meta-inputs (about the routing itself)

If the user asks “What would you do with this?” or “How would you classify this?”: → INVOKE: /meta $ARGUMENTS

Empty or trivial inputs

If the input is too short or vague to classify (“help”, “hi”, ”?”):

What are you working on? I can help with:
- Testing a claim or belief
- Making a decision
- Exploring a question or topic
- Processing a feeling
- Getting something done

Say what's on your mind and I'll route to the right analytical tool.

Inputs that don’t fit any category

If the input genuinely does not fit (jokes, greetings, translation requests, simple factual lookups):

• Respond naturally without routing to a skill
• Mention that analytical skills are available if they have a deeper question

Failure Modes

Depth Scaling

Default: 2x. These are floors.

Pre-Completion Checklist

• Input read and coarse type identified
• Rerouting rules applied (first match wins)
• Fine route selected with evidence
• Confidence assessed for both coarse and fine
• If low confidence: interpretations presented instead of auto-routing
• If compound input: dominant type identified, secondary noted
• Sub-orchestrator invoked with full original input as arguments
• Post-route verification noted (does output type match user want?)

Integration

• Use from: This is the entry point. Users invoke /auto when they don’t know which skill to use, or it can be the default handler for all input.
• Routes to: Any of the 15 sub-orchestrators: /claim, /viability, /decide, /search, /how, /want, /diagnose, /technical, /meta, /analyze, /emotion, /action, /create, /evaluate, /iterate, /next, /certainty
• Differs from /handle: /handle assumes the input is “handle this” — maximally vague delegation. /auto handles ANY input, including clear and specific inputs that just need routing.
• Differs from /wsib: /wsib recommends a skill for the user to invoke. /auto classifies and invokes directly.
• Differs from /meta: /meta provides orientation about the skill system. /auto uses the skill system on behalf of the user.
• Complementary: /fonss (find optimal next skill in sequence), /dtse (determine task-skill equivalence)