# Skill Router > Help users discover available skills and help Claudia pick the right one when a request is ambiguous. Two surfaces: discovery (user says "what can you do?", "/skills", "show me your skills") returns a categorized list; disambiguation (user's request matches 2+ skills) names the candidates and proceeds with the canonical one. Use when user asks about Claudia's capabilities, requests something ambiguous between adjacent skills, or seems unsure which skill they need. - Skill: `kbanc85/skill-router` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add kbanc85/skill-router` - Raw SKILL.md: https://api.skillmd.com/api/skills/kbanc85/skill-router/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: kbanc85 (https://skillmd.com/u/kbanc85) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/kbanc85/skill-router --- # Skill Router Two jobs: help the user find the skill they need, and help me (Claudia) pick the right skill when their request straddles two or more. ## Why this exists The shipped catalog has ~42 user-facing skills. Two common failure modes: 1. **Users don't know what's available.** They type "morning brief" because they've seen `/morning-brief` somewhere, but they don't know `/inbox-check`, `/pipeline-review`, or `/what-am-i-missing` exist. Friction. 2. **Ambiguous requests fire the wrong skill.** "Summarize this" could be `summarize-doc`, `capture-meeting`, or `file-document` depending on what comes next. I sometimes pick the wrong one, the user gets the wrong output, both of us waste a turn. This skill addresses both. ## Surface 1: Discovery When the user says "what can you do?", "/skills", "show me your skills", "list commands", "what skills do you have": Respond with a categorized list. Keep it scannable: ``` **📋 Daily flow** - /morning-brief start-of-day digest - /inbox-check email triage across configured accounts - /meeting-prep [person] one-page brief before a call - /capture-meeting process meeting notes after a call - /follow-up-draft draft a post-meeting thank-you **📊 Reviews & reflection** - /weekly-review end-of-week reflection - /growth-check monthly or quarterly self-development - /what-am-i-missing overdue, cooling, blind-spot sweep **💼 Pipeline & business** - /pipeline-review active opportunities + stalled items - /client-health health check across active clients - /financial-snapshot revenue, expenses, cash position **📚 Knowledge & memory** - /memory-audit what I know about an entity - /memory-health memory system stats - /wiki write or update a synthesized wiki page - /map-connections extract relationships across files - /deep-context full-context analysis for important decisions **✍️ Drafting** - /draft-reply general email response - /summarize-doc executive summary of a document - /auto-research iterate on a draft until it scores well **🏗 Setup** - /new-person create a relationship file - /new-workspace new project or client workspace - /file-document save a document with entity links - /ingest-sources batch-process multiple sources - /diagnose troubleshoot memory connectivity ``` Don't list every skill. List the ones a user is most likely to invoke directly. Internal skills (proactive ones like `commitment-detector`, `pattern-recognizer`, `risk-surfacer`) fire on their own and don't need to be in the discovery list. If the user asks `/skills ` or "what skills are about ", filter the list to skills whose names or descriptions match, and explain the cluster. Example for `/skills meeting`: ``` Three skills for meetings, in order of when they fire: - /meeting-prep [person] → before the call (one-page brief) - /capture-meeting → during or after (process notes) - /follow-up-draft → after (post-meeting email) ``` ## Surface 2: Disambiguation When the user's request matches 2+ skills, name the candidates briefly and proceed with the canonical one. Don't make the user choose; choose for them, and tell them what you chose. ### How to detect ambiguity A request is ambiguous when: - The trigger phrase appears in 2+ skill descriptions - The request is in one of the known overlap clusters (see references/overlap-clusters.md) - The artifact type is ambiguous (a "transcript" could be a meeting transcript → `capture-meeting`, or a research interview → `ingest-sources`, or just a generic document → `file-document`) ### How to disambiguate Pattern: "Sounds like X or Y. I'll do X. Say so if you wanted Y." Examples: > User: "Help me draft a follow-up" > Claudia: "Sounds like either `draft-reply` (general response) or `follow-up-draft` (post-meeting thank-you with meeting context). Was this from a call we had? If yes, `follow-up-draft`; if not, `draft-reply`. Defaulting to `follow-up-draft` since you said 'follow-up'." > User: "Summarize this meeting" > Claudia: "I'll use `capture-meeting` (extracts decisions, commitments, blockers from meeting notes). If you wanted a one-shot prose summary without filing as memories, say `summarize-doc` instead." > User: "What's going on?" > Claudia: "Default for that phrasing is `morning-brief`. Was that what you wanted, or did you mean `/what-am-i-missing` (risks and gaps), `pipeline-review` (deal status), or just an answer about a specific entity? Going with `morning-brief`." The pattern: pick the canonical, name the alternative, run. ### When NOT to disambiguate - The request is unambiguous. Don't manufacture options. - The user has been specific. "Draft a reply to this email" is `draft-reply`, no need to mention `follow-up-draft`. - The disambiguation explanation would be longer than the actual response. For short tasks, just do the canonical thing and let the user redirect. ## Overlap clusters (the canonical map) See `references/overlap-clusters.md` for the full map. The clusters I check most often: | Cluster | Canonical | Adjacent | |---------|-----------|----------| | Outbound messages | `draft-reply` (general), `follow-up-draft` (post-meeting) | `inbox-check` (triage before drafting) | | Memory views | `memory-audit` (content), `memory-health` (system), `diagnose` (connectivity) | | | Visualization | `brain` (3D web), `brain-monitor` (terminal) | | | Reflective cadences | `morning-brief` (daily) → `weekly-review` (weekly) → `growth-check` (monthly+) → `meditate` (session) | | | Meeting lifecycle | `meeting-prep` (before) → `capture-meeting` (during/after) → `follow-up-draft` (after, outbound) | | | Risks and gaps | `what-am-i-missing` (user-invoked) | `risk-surfacer` (proactive auto-fire) | | People and relationships | `relationship-tracker` (ongoing), `new-person` (create), `map-connections` (extract graph) | `connector-discovery` (external services, NOT people) | | Patterns/judgment/capability | `pattern-recognizer` (notice) → `judgment-awareness` (apply rules) → `capability-suggester` (propose commands) | `hire-agent` (propose new subagents) | | Inbound processing | `ingest-sources` (multi-doc), `file-document` (single doc), `capture-meeting` (meeting only), `summarize-doc` (no filing) | | ## Skill index integration The `skill-index.json` file at `skills/skill-index.json` is the structured catalog this skill reads. Each entry has: - `name`: slug - `description`: one-line description - `category`: which discovery category the skill falls in (daily, reviews, pipeline, knowledge, drafting, setup, internal) - `canonical_for`: list of request patterns where this skill is the canonical choice (used by disambiguation) - `see_also`: list of adjacent skills (set in PR3's see-also work) When skill-router is invoked, it loads skill-index.json and uses these fields. The discovery list above is generated from `category`. Disambiguation uses `canonical_for` and `see_also`. ## See also - `agent-dispatcher` for routing tasks to subagents (different concept: this is about which Claudia *skill* fires; agent-dispatcher is about which *subagent* gets a task) - `capability-suggester` for proposing *new* skills when patterns emerge that current skills don't cover ## Open questions for future versions - **Telemetry.** Logging which skills fire on which inputs would let me learn over time which routings are wrong and propose corrections via `capability-suggester`. Not in this version. - **Per-user customization.** Some users invoke `weekly-review` weekly; others never use it. The discovery list should adapt to the user's actual usage over time. Not in this version. - **Skill search by example.** "Show me a skill that does X for Y" → semantic search over skill descriptions. Not in this version; today the user filters by keyword via `/skills `.