skill-router
- Repo stars 253
- Author updated Live
- Author repo claudia
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @kbanc85 · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-router
description: Help users discover available skills and help Claudia pick the right one when a request is ambig…
category: engineering
runtime: no special runtime
---
# skill-router output preview
## PART A: Task fit
- Use case: 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..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Why this exists / Surface 1: Discovery / Surface 2: Disambiguation” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “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.”.
- **02** When the source has headings, the agent prioritizes “Why this exists / Surface 1: Discovery / Surface 2: Disambiguation” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/morning-brief`, `/inbox-check`, `/pipeline-review`, `/what-am-i-missing`, `/meeting-prep`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Why this exists / Surface 1: Discovery / Surface 2: Disambiguation”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skill-router
description: Help users discover available skills and help Claudia pick the right one when a request is ambig…
category: engineering
source: kbanc85/claudia
---
# skill-router
## When to use
- Help users discover available skills and help Claudia pick the right one when a request is ambiguous. Two surfaces: di…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Why this exists / Surface 1: Discovery / Surface 2: Disambiguation” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skill-router" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Why this exists / Surface 1: Discovery / Surface 2: Disambiguation
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} 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:
- Users don't know what's available. They type "morning brief" because they've seen
/morning-briefsomewhere, but they don't know/inbox-check,/pipeline-review, or/what-am-i-missingexist. Friction. - Ambiguous requests fire the wrong skill. "Summarize this" could be
summarize-doc,capture-meeting, orfile-documentdepending 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 <topic> or "what skills are about /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) orfollow-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 tofollow-up-draftsince 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, saysummarize-docinstead."
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 withmorning-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 mentionfollow-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 template-v2/.claude/skills/skill-index.json is the structured catalog this skill reads. Each entry has:
name: slugdescription: one-line descriptioncategory: 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-dispatcherfor routing tasks to subagents (different concept: this is about which Claudia skill fires; agent-dispatcher is about which subagent gets a task)capability-suggesterfor 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-reviewweekly; 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 <keyword>.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review