$npx -y skills add Rune-kit/rune --skill skill-routerMeta-enforcement layer that routes EVERY agent action through the correct skill. MUST check this routing table before ANY response involving code, files, or technical decisions. Default: route to rune:cook for code tasks. Prevents rationalization, enforces check-before-act discip
| 1 | ## Live Routing Context |
| 2 | |
| 3 | Routing overrides (if available): !`cat .rune/metrics/routing-overrides.json 2>/dev/null || echo "No adaptive routing rules active."` |
| 4 | |
| 5 | Recent skill usage: !`cat .rune/metrics/skills.json 2>/dev/null | head -20 || echo "No metrics collected yet."` |
| 6 | |
| 7 | # skill-router |
| 8 | |
| 9 | ## Purpose |
| 10 | |
| 11 | The missing enforcement layer for Rune. While individual skills have HARD-GATEs and constraints, nothing forces the agent to *check* for the right skill before acting. `skill-router` fixes this by intercepting every user request and routing it through the correct skill(s) before any code is written, any file is read, or any clarifying question is asked. |
| 12 | |
| 13 | This is L0 — it sits above L1 orchestrators. It doesn't do work itself; it ensures the right skill does the work. |
| 14 | |
| 15 | ## Triggers |
| 16 | |
| 17 | - **ALWAYS** — This skill is conceptually active on every user message |
| 18 | - Loaded via system prompt or plugin description, not invoked manually |
| 19 | - The agent MUST internalize this routing table and apply it before every response |
| 20 | |
| 21 | ## Calls (outbound connections) |
| 22 | |
| 23 | - Any skill (L1-L3): routes to the correct skill based on intent detection |
| 24 | |
| 25 | ## Called By (inbound connections) |
| 26 | |
| 27 | - None — this is the entry point. Nothing calls skill-router; it IS the first check. |
| 28 | |
| 29 | ## Workflow |
| 30 | |
| 31 | ### Step 0 — Check Routing Overrides (H3 Adaptive Routing) |
| 32 | |
| 33 | Before standard routing, check if adaptive routing rules exist: |
| 34 | |
| 35 | 1. Use `Read` on `.rune/metrics/routing-overrides.json` |
| 36 | 2. If the file exists and has active rules, scan each rule's `condition` against the current user intent |
| 37 | 3. If a rule matches: |
| 38 | - Apply the override action (e.g., "route to problem-solver before debug") |
| 39 | - Log: "Adaptive routing: applying rule [id] — [action]" |
| 40 | 4. If no file exists or no rules match, proceed to standard routing (Step 1) |
| 41 | |
| 42 | **Override constraints**: |
| 43 | - Overrides MUST NOT bypass layer discipline (L3 cannot call L1) |
| 44 | - Overrides MUST NOT skip quality gates (sentinel, preflight, verification) |
| 45 | - Overrides MUST NOT route to non-existent skills |
| 46 | - If an override seems wrong, announce it and let user decide to keep or disable |
| 47 | |
| 48 | **Model hint support** (Adaptive Model Re-balancing): |
| 49 | - Override entries may include `"model_hint": "opus"` — this signals that a skill previously failed at sonnet-level and needed opus reasoning depth |
| 50 | - When a model_hint is present, announce: "Adaptive routing: this skill previously required opus-level reasoning for [context]. Escalating model." |
| 51 | - Model hints are written by cook Phase 8 when debug-fix loops hit max retries on the same error pattern |
| 52 | - Model hints do NOT override explicit user model preferences |
| 53 | |
| 54 | ### Context Efficiency (Trigger-Table Pattern) |
| 55 | |
| 56 | Skill-router's routing table above IS the trigger table — it maps keywords to skill paths without loading any skill content. Skills are loaded on-demand via the Skill tool only when routed. This keeps baseline context usage minimal. |
| 57 | |
| 58 | **Rules for context efficiency:** |
| 59 | - NEVER read a SKILL.md to decide routing — use the routing table keywords |
| 60 | - NEVER load multiple skills speculatively — route to ONE, let it chain if needed |
| 61 | - Skill content is loaded by the Skill tool, not by skill-router reading files |
| 62 | |
| 63 | ### Step 0.25 — Request Classifier (Fast-Path Filter) |
| 64 | |
| 65 | Before intent classification, categorize the request into one of 5 types. This determines the **enforcement level** — how strictly routing must be followed. |
| 66 | |
| 67 | | Request Type | Keywords / Signals | Enforcement | Action | |
| 68 | |---|---|---|---| |
| 69 | | `CODE_CHANGE` | "build", "implement", "add", "create", "fix", "refactor", "update code" | **FULL** | cook mandatory, no exceptions | |
| 70 | | `QUESTION` | "what is", "how does", "explain", "why" | **LITE** | Check if a skill has domain knowledge first; answer directly if no skill matches | |
| 71 | | `DEBUG_REQUEST` | "error", "bug", "not working", "broken", "crash", "fails" | **FULL** | debug skill mandatory | |
| 72 | | `REVIEW_REQUEST` | "review", "check", "audit", "look at this code" | **FULL** | review skill mandatory | |
| 73 | | `EXPLORE` | "find", "search", "where is", "show me", "list" | **LITE** | scout if codebase-related; answer directly if general | |
| 74 | |
| 75 | **Enforcement levels:** |
| 76 | - **FULL** → MUST route through a skill. Writing code without skill invocation = protocol violation. |
| 77 | - **LITE** → SHOULD check if a skill applies. Can answer directly if no skill matches and the response involves no code changes. |
| 78 | |
| 79 | **Escape hatch**: If request is clearly trivial (< 5 LOC change, single-line fix, user says "just do it"), classify as CODE_CHANGE but cook activates Fast Mode automatically. |
| 80 | |
| 81 | ### Step 0.3 |