Orchestrator Skill Design

Input: $ARGUMENTS

Step 1: Define the Orchestrator’s Domain

An orchestrator routes — it doesn’t analyze. Define what space it covers.

ORCHESTRATOR NAME: [abbreviation]
DOMAIN: [what kind of inputs it handles]
ROUTES TO: [how many target skills]
GOAL: [what the user gets — the right skill for their input]

Rule: An orchestrator should never produce its own analysis. Its only job is dispatching to the right skill.

Step 2: Design the Classification Scheme

Define how inputs get categorized.

CLASSIFICATION SCHEME:

| Class | Signal Words / Patterns | Target Skill | Example Input |
|-------|------------------------|-------------|---------------|
| [class 1] | [what to look for] | /[skill] | [example] |
| [class 2] | [what to look for] | /[skill] | [example] |
| [class 3] | [what to look for] | /[skill] | [example] |
| [class 4] | [what to look for] | /[skill] | [example] |
| [class 5] | [what to look for] | /[skill] | [example] |

Aim for 4-8 classes. Fewer than 4 means the orchestrator is too narrow. More than 8 means it should be split into sub-orchestrators.

Step 3: Design the Routing Logic

Define the decision process from input to dispatch.

ROUTING LOGIC:

1. SCAN: Read the input for signal words and patterns
2. CLASSIFY: Match to the strongest class
   - If clear match → route directly
   - If multiple matches → go to Step 4 (ambiguity handling)
   - If no match → go to Step 5 (fallback handling)
3. CONFIRM: State the classification and reasoning in one line
4. DISPATCH: → INVOKE: /[target_skill] [input]

Rule: Routing should take one pass. If classification requires deep analysis, the orchestrator scope is wrong.

Step 4: Handle Ambiguous Inputs

Some inputs match multiple classes. Design the tiebreaker.

AMBIGUITY HANDLING:

STRATEGY: [pick one]
- PRIORITY: Use a fixed priority order (class 1 > class 2 > class 3)
- DECOMPOSE: Split the input and route parts separately
- ASK: Present the top 2 matches and let the user choose
- DEFAULT: Route to the most general skill

PRIORITY ORDER (if using PRIORITY):
1. [highest priority class] — because [reason]
2. [next class]
3. [next class]
...

Step 5: Handle No-Match Inputs

Every input must go somewhere. No input should fall through.

FALLBACK HANDLING:

1. Check if input is malformed → ask user to rephrase
2. Check if input belongs to a different orchestrator → redirect
3. If genuinely novel → route to the most exploratory/general skill
4. Never return "I don't know what to do with this"

DEFAULT ROUTE: /[fallback skill]
REASON: [why this is the safest default]

Step 6: Test With Diverse Inputs

Verify routing accuracy across input types.

ROUTING TEST:

| # | Input | Expected Class | Routed To | Correct? |
|---|-------|---------------|-----------|----------|
| 1 | [clear input for class 1] | [class 1] | /[skill] | [yes/no] |
| 2 | [clear input for class 2] | [class 2] | /[skill] | [yes/no] |
| 3 | [ambiguous input] | [class ?] | /[skill] | [yes/no] |
| 4 | [edge case input] | [class ?] | /[skill] | [yes/no] |
| 5 | [input from outside domain] | [fallback] | /[skill] | [yes/no] |

If accuracy is below 80%, revise the classification scheme.

Step 7: Write the Orchestrator

Produce the complete SKILL.md.

ORCHESTRATOR FILE:

---
name: "[abbreviation] - [Full Name]"
description: [one sentence — routes X type of input to the right skill]
---

# [Full Name]

**Input**: $ARGUMENTS

## Classify
[classification table]

## Route
[routing logic with INVOKE statements]

## Integration
[list of all target skills]

Integration

Use with:

/chns -> Ensure target skills have compatible input contracts
/injc -> Add injectable checks before routing (e.g., input validation)
/stnl -> Verify each target skill works standalone after dispatch

orcs - Orchestrator Skill Design