Skill Router

Skill Router

Analyze tasks and recommend optimal skill workflows.

How It Works

1. Analyze the task - Understand what user is trying to accomplish
2. Match to workflow pattern - Find best skill sequence for the task type
3. Present with rationale - Explain why each skill and in what order
4. Let user modify - Accept, modify, or skip to specific step
5. Execute sequentially - Run skills in order, passing context between them

Workflow Pattern Library

Design & UI

Development

Debugging & Quality

Content & Documentation

Infrastructure

Task Recognition Signals

Look for these keywords to identify task type:

Presenting the Workflow

Use AskUserQuestion to present the recommended workflow:

**Recommended Workflow for:** [task description]

1. **[skill-name]** - [what it does for this task]
2. **[skill-name]** - [what it does for this task]
3. **[skill-name]** - [what it does for this task]

**Why this order:** [brief rationale]

Question format:

• header: "Workflow"
• multiSelect: false
• options:
  • "Accept workflow" - Run all steps in sequence
  • "Modify workflow" - Let me adjust the steps
  • "Skip to step" - Jump to a specific skill
  • "Just show skills" - Show individual options instead

Workflow Execution

When user accepts:

1. Run Mandatory Quality Gate first - Think through data flow, async, race conditions
2. Invoke first skill
3. After completion, pass relevant context to next skill
4. Continue through workflow
5. Self-roast before claiming done - Actively try to break your own code
6. Offer to run code-review at end if not included

When user wants to modify:

1. Present all skills in workflow as multiSelect list
2. Let them remove/reorder
3. Ask if they want to add any other skills
4. Execute modified workflow

Context Passing

Maintain a workflow context that includes:

• Original task description
• Outputs/decisions from each completed skill
• Any user feedback during execution

Pass this context when invoking each skill so they build on previous work.

Rules

• Always present workflow first - Never auto-execute without approval
• Explain the rationale - Help user understand why this sequence
• Allow modification - User knows their needs best
• Pass context forward - Each skill should know what came before
• Offer code-review - Suggest at end of any coding workflow
• Handle unknowns - If task doesn't match patterns, ask clarifying questions first
• ⚠️ MANDATORY: Run Quality Gate - Before ANY code, think through data/async/race conditions
• ⚠️ MANDATORY: Self-Roast - Before claiming done, actively try to break your code
• No half-assed work - If you find issues, fix them. Don't ship with known problems.

Google-Engineer Production Checklist (MANDATORY)

Every implementation MUST include solutions for ALL of these:

Defensive Programming Patterns:

• Validate inputs at system boundaries (API routes, form submissions)
• Never trust client data on the server
• Use TypeScript strict mode
• Prefer immutable updates
• Handle null/undefined explicitly
• Log errors with context (not just the error message)

Mandatory Quality Gate (ALL TASKS)

⚠️ THIS IS NOT OPTIONAL - APPLIES TO EVERY TASK, EVERY FIX, EVERY FEATURE

BEFORE writing ANY code, ask yourself:

1. Understand the data flow

   • Where does the data come from?
   • What updates the data?
   • What depends on fresh data?

2. Check async/await ordering

   • Does this code depend on data that's fetched asynchronously?
   • Am I updating UI state BEFORE or AFTER the data is ready?
   • Will the user see stale data flash before the update?

3. Race condition checklist

   • Can the user trigger this action multiple times rapidly?
   • What happens if async operation A completes after operation B started?
   • Is there shared state that could be corrupted?

4. State timing questions

   • When I call setState, what data will the next render see?
   • Am I reading from state that was JUST updated (it won't be fresh yet)?
   • Should I await something before showing UI?

Red flags that indicate duct tape:

• "It works but might flash wrong data briefly" → NOT DONE
• "The data updates on the next render" → FIX THE ORDERING
• "User just needs to refresh" → BUILD IT PROPERLY
• "Works if you don't click too fast" → HANDLE THE RACE CONDITION
• Setting state then immediately reading from array that state updates → AWAIT FIRST

Proper pattern for UI that depends on fresh data:

// WRONG - duct tape
doAsyncThing();
setShowModal(true); // Modal sees stale data

// RIGHT - proper
await doAsyncThing();
setShowModal(true); // Modal sees fresh data

Self-Roast Protocol (MANDATORY BEFORE "DONE")

After implementing ANY change, BEFORE claiming it's done:

1. Actively try to break it - Don't just test the happy path

   • What if user clicks twice rapidly?
   • What if the network is slow?
   • What if data is missing/null?
   • What if user does things out of order?

2. Question your assumptions

   • "Will this always be true?" (probably not)
   • "What if this state is stale?"
   • "What happens on first load vs subsequent loads?"

3. Roast your own code

   • Look at what you wrote and ask: "What's wrong with this?"
   • If you can't find anything wrong, you're not looking hard enough
   • Pretend a senior dev is reviewing - what would they critique?

4. Check these specific things:

   • Async operations complete before dependent code runs
   • State updates are awaited before UI reads from them
   • Error cases are handled (not just logged)
   • Loading states exist where needed
   • User can't break it with rapid clicks
   • Works on first load, not just after refresh

If you find issues during self-roast → FIX THEM FIRST

Don't tell the user "it works" and then list caveats. Fix the caveats.

Build It Right Protocol

BEFORE starting any feature implementation:

1. Define "done" - Write a brief spec listing all user-facing touchpoints:

   • What can users CREATE?
   • What can users READ/VIEW?
   • What can users UPDATE?
   • What can users DELETE?
   • What can users CONFIGURE?

2. Ask clarifying questions - If any part is ambiguous, ask BEFORE coding:

   • "Should users be able to view X later?"
   • "How should users configure this?"
   • "What happens when Y occurs?"

3. Get approval on the spec - Present the full scope and confirm before implementing

DURING implementation:

4. No duct tape - If you find yourself saying:

   • "You can run this SQL command to..." → Build the UI instead
   • "We can add that later..." → Add it now or explicitly descope it
   • "For now, just..." → Either do it properly or don't do it

5. Complete the loop - Every feature needs:

   • The core functionality
   • A way to view/access it
   • A way to configure it (if applicable)
   • Error handling for edge cases

AFTER implementation:

6. Verify completeness - Answer these before marking done:

   • "What can a user do now that they couldn't before?"
   • "Walk me through the complete user flow"
   • "Is there any manual step required?" (if yes, not done)

7. Never claim "done" if:

   • Tests are failing
   • Implementation is partial
   • Any workarounds are required
   • Configuration requires raw SQL/CLI commands

Fallback: Individual Skill Selection

If user prefers to pick individual skills or task doesn't match patterns:

Skill Categories

Development & Coding

• frontend-design - Production-grade UI with high design quality
• frontend-development - React/TypeScript patterns, performance
• backend-development - APIs, databases, auth, microservices
• code-review - Security, quality, best practices
• systematic-debugging - Root cause analysis and fixes

Planning & Thinking

• brainstorming - Refine ideas through collaborative questioning
• writing-plans - Design implementation strategies
• executing-plans - Execute plans in controlled batches

Design & Media

• aesthetic - Beautiful interfaces, design principles
• canvas-design - Posters, art, static visual designs
• ai-multimodal - Analyze/generate audio, video, images, PDFs
• chrome-devtools - Browser automation, screenshots

Testing & Quality

• webapp-testing - End-to-end testing
• condition-based-waiting - Fix flaky tests
• defense-in-depth - Multi-layer validation

Documentation & Research

• docs-seeker - Find technical docs
• prompt-engineering - Write LLM prompts
• content-research-writer - Research and write with citations

Infrastructure & Tools

• mcp-builder - Create MCP servers
• mcp-management - Discover/execute MCP tools
• devops - Cloudflare, Docker, GCP
• databases - MongoDB, PostgreSQL