Skill Router

Skill Router

This project ships workflow skills (how to approach a type of work) and action skills (how to do a specific thing correctly). Pick from the map below. Multiple can apply — chain them.

Decision flowchart

Task arrives
  │
  ├── Vague idea, fuzzy goal ─────────────────→ idea-refine
  ├── Need a spec before building ────────────→ /spec  (produces SPEC.md)
  ├── Need a plan from a spec ────────────────→ /plan  (produces tasks/plan.md)
  ├── About to plan non-trivial work ─────────→ pre-planning
  │
  ├── Implementing something ─────────────────→ /build  (or: incremental-implementation)
  │     ├── Implement the whole plan (requires approval) ─→ /build auto
  │     ├── UI / React / component work ──────→ frontend-ui-engineering
  │     ├── HTTP / API / contract design ─────→ api-design
  │     └── Writing tests first ──────────────→ tdd
  │
  ├── Non-trivial decision under uncertainty ─→ doubt-driven-development
  │
  ├── Something is broken ────────────────────→ debugging
  │     └── Looking for classes of bugs ──────→ hunting-bugs
  │
  ├── Performance concern ────────────────────→ performance-profiling
  ├── Security review / threat model ─────────→ security-deep-dive
  │
  ├── Reviewing code / PR ────────────────────→ pr-review  (also: code-review)
  │     └── Review-fix until clean ───────────→ pr-review loop  (fresh subagent per round)
  ├── Simplifying code ───────────────────────→ code-simplification
  ├── Whole-codebase audit ───────────────────→ codebase-audit
  ├── Measuring code (LOC, complexity, dup) ──→ code-metrics
  │
  ├── Writing prose (blog, article, docs) ────→ no-ai-slop
  ├── Writing an ADR / architecture doc ──────→ documentation-adrs
  │
  ├── Pre-launch / deploy readiness ──────────→ /ship  (parallel review, human go/no-go)
  │
  └── Action skills (narrow, tool-specific):
        ├── Adding a dependency ──────────────→ evaluating-dependencies
        │     ├── npm/pnpm/yarn/bun ─────────→ + node-package-management
        │     └── nuget / dotnet add ────────→ + nuget-package-management
        ├── Committing ──────────────────────→ commit
        ├── Pushing ─────────────────────────→ push
        ├── Opening a PR ────────────────────→ make-pr
        ├── Port conflict / starting dev ────→ managing-ports
        ├── Cloning an Azure DevOps project ─→ azure-init
        ├── Recursive file deletion ──────────→ safe-delete
        ├── Browser automation / scraping ───→ chrome-devtools
        ├── Authoring a new skill ───────────→ validate-skill
        └── Save or recall knowledge ────────→ knowledge  (/knowledge store | /knowledge recall <topic>)

Rules

1. Check the router before starting non-trivial work. Vague prompts default to idea-refine. "Build X" without a spec defaults to /spec first.
2. Workflow skills are chainable. A typical feature: /spec → /plan → /build → pr-review loop → push → make-pr. The push and make-pr skills run the review loop themselves when it hasn't already passed on the current HEAD. The full autonomous path: /spec → /build auto. All paths require explicit human approval before execution; no step auto-deploys or runs destructive operations without sign-off.
3. Action skills gate specific tool calls. Installing a package? evaluating-dependencies first. Committing? commit. Opening a PR? make-pr. These are enforced by the skill-router plugin's PreToolUse advisor where it applies — but consult them regardless.
4. Skills are not suggestions. When a skill applies, follow its steps in order. Skipping the verification step of a workflow skill is the same as not running it.
5. When multiple apply, run them in sequence. Example: a UI feature → pre-planning → frontend-ui-engineering → incremental-implementation → tdd → pr-review.

Core operating behaviors

These apply across every skill.

1. Surface assumptions before implementing

Before any non-trivial implementation, list the assumptions you're about to make. If the user doesn't correct them, proceed. Silent assumptions are the #1 source of wasted work.

2. Manage your own confusion

When the spec contradicts the code, or one source contradicts another: stop, name the conflict, present the tradeoff or ask. Do not guess.

3. Push back when warranted

Not a yes-machine. When an approach has a concrete downside (latency, security, maintenance), say so once, propose an alternative, then accept the decision if overridden.

4. Prefer boring, obvious solutions

Three similar lines beats a premature abstraction. Don't design for hypothetical future requirements. If the change is 100 lines and you wrote 500, you failed.

5. Scope discipline

Touch only what the task requires. Don't delete comments you don't understand. Don't refactor adjacent code "while you're there." Don't add features not in the spec.

6. Verify, don't assume

A task isn't done until there's evidence — passing tests, build output, runtime check. "Looks right" is not evidence.

Quick reference

Failure modes

• Starting to code without checking the router (most common).
• Picking the first match instead of the best match.
• Following part of a skill and skipping verification.
• Inventing a skill that doesn't exist — only the skills listed above are real.