Skills Selector

Skills Selector — The Skill That Picks Skills

Prime directive: you are the first gate for every task. Decide which skill(s) deserve to load, or declare that none are needed. Every token spent on an unused skill is a token stolen from the user's real work.

Why this skill exists

Loading a skill injects hundreds to thousands of tokens into the context. Many CLIs now ship 20–80+ skills. Without a gatekeeper, every plausible match fires, the context fills with orchestration noise, and the model gets slower, more expensive, and more confused. skills-selector fixes that by running once at the top of a task and committing to a minimal, justified selection.

This skill is intentionally short. If you want depth, call the chosen skill — don't add it here.

Decision-native selection

Treat selection as a bounded decision workflow over one shared state:

refined prompt or current request + executor/catalog facts
        -> typed selection questions evaluated together
        -> deterministic policy clamps
        -> SKILLS selection block
        -> chosen skill(s)

The state contains only the objective, confirmed context, explicit user routes, available catalog entries, platform, risk, and verification shape. Evaluate these independent questions once: intent (Choice from the table), primary_skill (Choice from the available catalog plus none), secondary_skill (Choice from the remaining catalog plus none), heavy_signal (Noul), budget (Score: low/medium/high), and route_fit (Score). Keep the answer space declared; the selector never invents a skill or emits free-form routing JSON for another component to parse.

Use the static catalog and rules as the default. A calibrated scorer is optional, model-agnostic, and advisory until local validation supports enforcement. Its probabilities are routing signals, not correctness proof. If it is missing, invalid, slow, or below a calibrated gate, mark confidence unavailable and use the static catalog, SKILLS: [], or a sharp clarification as appropriate. Never compensate for uncertainty by selecting a heavier skill or more skills.

Protocol — run exactly these steps, in order

0. Consume the EXEC-MAP contract if present (skip re-classification)

If stage-0 (senior-prompt-engineer) already ran, an EXEC-MAP v1 block is in context. Consume it — do not re-classify from scratch:

• Take intent directly as the primary intent (skip step 1).
• Seed candidates from EXEC-MAP.skills (skip step 2's catalog lookup; still run step 3 rank/prune to validate, cap at 2, and drop heavy skills lacking signal).
• Carry effort/tokens into BUDGET.
• Add MAP: consumed to the emitted block so the audit trail shows stage-0's work wasn't redone.
• Validate skills, intent, effort, and router_fallback against the current catalog and platform. Preserve the canonical router, router_mode, router_confidence, and router_fallback fields losslessly when valid; otherwise use the static policy values.

Only fall through to steps 1–2 when no EXEC-MAP block exists.

1. Build the shared state and classify once — only if no EXEC-MAP

Construct the bounded state described above. Evaluate the typed questions once; do not ask separate model calls to classify intent, choose skills, and estimate budget. Use the artifact the user expects at the end to resolve ambiguity.

1a. Classify the request (inline, silent) — only if no EXEC-MAP

Assign the user's turn to one primary intent from:

Ambiguous? Ask yourself: what artifact does the user expect at the end? That answer usually disambiguates.

2. Match candidates from the catalog

Look up the intent in the Catalog below. A request can match multiple rows — that's fine, rank them next.

3. Rank and prune (token-aware)

Apply these rules, in order — each one can drop a candidate:

1. RTK Bypass Dispatch for Boilerplate. If the task is a repetitive, mechanical fix (lint, typecheck, test fixes in test files, or i18n), ALWAYS select smart-dispatch and prioritize the correct bypass command (e.g., rtk gemini --yolo as primary). Emit BUDGET: low.
2. Trivial requests stay inline. If the task is a single-line edit, a status check, a factual question, or something the model can handle in under ~3 tool calls: select nothing. Emit SKILLS: [].
3. Cap at 2 skills per turn. Orchestration cost grows super-linearly. If you picked 3+, drop the lowest-weight one or split the work.
4. Prefer narrow over broad. git-commit beats git-master for a commit. ui-polisher beats ui-ux-pro-max for a minor CSS tweak.
5. Heavy skills need explicit signal. ui-ux-pro-max, frontend-design, gsd:new-project, superpowers (if present), remotion-best-practices, heygen-best-practices, mcp-builder, Agent Development — only if the user names their domain or explicitly asks for depth.
6. Never chain design + plan + build in one turn. Pick the nearest waypoint and let the user confirm before escalating.
7. If a domain skill and a meta-skill both match, pick the domain one. E.g. for "write a PR", git-pr-create beats smart-dispatch.
8. Apply typed-router output only after policy clamps. Explicit user routes, deterministic bypasses, heavy-skill signals, catalog availability, and the two-skill cap always win.
9. Fail open to the static catalog. Low confidence, timeout, malformed output, or missing scorer credentials must not trigger quality escalation; select the static route, inline handling, or ask one sharp question.

4. Emit the selection block, then hand off

Print exactly one block at the top of your response, then stop this skill and let the chosen skill(s) take over. Do not repeat the block. Do not wrap it in prose.

SKILLS: [skill-a, skill-b]   # [] means "none — handle inline"
INTENT: <one-word>
REASON: <≤15 words, concrete>
BUDGET: <low | medium | high>   # token/context intent
MAP:    <consumed | none>       # consumed = seeded from senior-prompt-engineer EXEC-MAP
NEXT:   <first concrete action>
router: <heuristic | typed-scorer>
router_mode: <heuristic | shadow | advisory | enforce>
router_confidence: <0.00-1.00 | unavailable>
router_fallback: <ask | static-catalog | balanced | none>

If SKILLS: [], proceed inline without invoking any skill. If one or more skills are selected, invoke them via the platform's Skill mechanism (Claude Code: Skill tool; Codex: /<skill> or skill invocation; Gemini: slash command / skill call). Never paraphrase a skill — always invoke it so its authoritative content drives behavior.

Catalog — keyword → skill (keep compact; depth lives inside each skill)

Legend: P = platform scope (C=Claude, X=Codex, G=Gemini, L=lemon-code built-in, any=portable). Weight is a rough token cost: · tiny, ·· small, ··· medium, ···· heavy. Prefer lower-weight skills when the task is small.

Planning & orchestration

Design & UI

Frontend & mobile code

Backend / language

Git workflow

Quality, testing, debugging

AI / agents / MCP / skills

Media, content, marketing

Documents & files

Harness, config, workflow

GSD (Get-Shit-Done) family — decimal phases, UAT, milestones

Activate only when the user is clearly inside a GSD workflow (you'll see a .planning/ directory, a phase number, or explicit GSD vocabulary). Map 1:1 to the slash command: gsd:do, gsd:next, gsd:progress, gsd:plan-phase, gsd:execute-phase, gsd:verify-work, gsd:add-tests, gsd:debug, gsd:ship, gsd:review, gsd:audit-uat, gsd:add-backlog, gsd:new-milestone, gsd:complete-milestone, gsd:cleanup, gsd:health, etc.

Rule: never pre-emptively open a GSD command outside a GSD project.

Matching heuristics — fast patterns

The table above is authoritative. This list is a quick regex-ish cheatsheet for the first pass:

• \bcommit\b|\bcommita\b|git add → git-commit
• \bpr\b|pull request|merge request → git-pr-create
• \breview(ing)?\b|audit diff → git-review or security-review
• \bbranch\b|checkout|switch → git-branch
• changelog|release notes → git-changelog
• design|redesign|landing|hero|figma → frontend-design or ui-ux-pro-max
• accessibility|a11y|wcag|contrast|keyboard nav → ui-ux-pro-max
• polish|micro(-| )interaction|spacing → ui-polisher
• react native|expo|android|ios\b → react-native + possibly vercel-react-native-skills
• mcp server|fastmcp|mcp tool → mcp-builder / create-mcp
• new skill|create a skill|skill md → skill-creator
• prompt cach(e|ing)|anthropic sdk|claude api → claude-api
• e2e|playwright|cypress → webapp-testing
• unit test|tdd|vitest|jest|bun test → testing / backend-testing
• \bapi-test-loop\b|validate api|test backend api|curl api → api-test-loop
• \bpostman-generator\b|postman|newman|collection|env|validate postman|valide → postman-generator
• bug|error|stack trace|regression → auto-fix first, escalate to systematic-debugging
• pod install.*error|NitroModules|Unable to find a specification|BUILD FAILED|update rules|update docs → error-fix-loop
• deploy|docker|k8s|pipeline|ci/cd → devops
• landing copy|headline|cta|pitch → copywriting
• linkedin|tweet|instagram|post → social-content
• xlsx|excel|spreadsheet → xlsx
• settings\.json|hook|permission|keybind → update-config / keybindings-help
• loop|every \d+ (min|hour)|cron → loop / schedule
• \bgsd\b|\.planning|phase \d+\.\d+ → GSD family
• architecture|how does .* relate|understand the codebase + graphify-out/ exists → graphify (query mode)

Multiple matches? Apply step 3 (rank & prune) before emitting.

Examples

Trivial Q&A User: "what's the file that sets our default theme?" → SKILLS: [] — answer inline with a grep. No skill earns its keep here.

Clear single-skill match User: "open a PR with the staged changes" → SKILLS: [git-pr-create] | INTENT: git-op | REASON: direct PR request | BUDGET: low | NEXT: run git status + git diff.

Conflict, pick narrower User: "create the commit" → SKILLS: [git-commit] (not git-master) | INTENT: git-op | REASON: narrow beats broad | BUDGET: low.

Design: light vs heavy User: "adjust header spacing" → SKILLS: [ui-polisher]. User: "redesign the landing with a bolder identity" → SKILLS: [frontend-design] (or ui-ux-pro-max if a system-level sweep is asked).

Planning + build — do NOT chain User: "plan and implement watchlist feature X" → First turn: SKILLS: [smart-dispatch] | REASON: multi-model plan. Let it emit the dispatch table, then the user confirms before building.

Bug report User: "breaking with TS2322 in agent.ts:210" → SKILLS: [auto-fix] — pattern-matched, cheap. If 2 fix attempts fail, escalate to systematic-debugging.

New skill User: "create a skill to review SQL" → SKILLS: [skills-selector, skill-creator]? No — skills-selector is already running. Emit SKILLS: [skill-creator].

Rules & guardrails

1. Self-recursion is forbidden. Never put skills-selector in the SKILLS: list. You are the chooser, not the choice.
2. No silent escalation. If you picked a heavy skill, your REASON must name the signal that justified it.
3. Announce before you invoke. Always emit the block. Never call a skill without emitting the plan first — the block is the audit trail.
4. Respect user overrides. If the user explicitly names a skill ("use ui-ux-pro-max for this"), pass it through — your job is scoping, not vetoing.
5. Language stays with the user. Keep the selection block in the user's language if non-English (US English/pt-BR OK). Identifiers (skill names, SKILLS: key) stay in English.
6. Portability. If the selected skill doesn't exist on the current platform, downgrade to the closest match on the same row of the catalog; note the substitution in REASON.
7. Stop at selection. After the block, hand off. Do not continue executing the selected skill's body — invoke it via the platform's Skill mechanism.
8. If nothing fits, emit []. No-skill is a valid, often correct, answer. The default is to do the work inline with the base tools.

Output template (copy exactly)

SKILLS: [<csv or empty>]
INTENT: <intent-label>
REASON: <≤15 words>
BUDGET: <low|medium|high>
MAP:    <consumed | none>
NEXT:   <first concrete action>

That block — or silence plus inline work — is the entire surface of this skill. Depth belongs to the skills you dispatch, not here.