Skill Router

This repo's skills are step-by-step processes, not reference docs. The hard part is loading the right one at the right moment — then following it fully. This skill is the map: identify what you're doing, pick the matching skill(s), work in lifecycle order, and chain to the next phase when done.

The Rule (mandatory)

If there is even a ~1% chance a skill applies, invoke it before acting — before clarifying questions, before writing code, before "just doing it." Check the routing table below first. If a loaded skill turns out not to fit, set it aside; but you do not get to skip the check, and partial application counts as skipping. Confidence without the process is exactly the failure these skills exist to prevent.

Precedence: the user always wins. If the user — or CLAUDE.md/AGENTS.md — says not to use a skill, follow the user. Skills override your default behavior, never an explicit instruction.

Before routing: confirm [[agent-guardrails]] is active — destructive data ops, secret access, and security bypasses require explicit user approval regardless of which skill you pick next.

Wrong skill or partial application is worse than no skill — you get confidence without the process. When several skills apply, pick a primary skill for the current step and pull in secondary skills only when the diff or task touches their domain ([[context-curation]] keeps the load lean).

When to Use

• Start of a session — before improvising a workflow that already exists here
• User request could match multiple skills — need disambiguation
• Unsure whether to spec, plan, or jump to code
• Task spans phases — need the lifecycle order
• Recurring work type might need a new skill ([[skill-creator]])

Skip re-reading the full map when you're mid-phase and the next skill is obvious (e.g. finished [[spec-first]], now load [[work-planning]]). Not a substitute for any domain skill — routing points you to the process; the process does the work.

Process

1. Classify the request — what kind of work is this?

Read the user's ask for intent, not keywords alone:

If the request mixes phases ("build and ship today"), still sequence — define/plan may be a 5-minute pass, not skipped silently when risk is high.

2. Match intent to a skill

Use the primary intent — the thing the user most needs done right now.

Define — clarify before building

Plan — order the work

Build — implement correctly

Verify — prove it works

Review — check before merge

Ship — get it out safely

Operate — run and learn in prod

Grow — traffic, engagement, retention

Meta — this repo's skills

3. Disambiguate when several skills seem to fit

When still unsure, prefer the skill earlier in the lifecycle — spec beats code, measure beats optimize.

4. Use common recipes — multi-skill chains

These are typical sequences; run one primary skill at a time, chain when the phase completes.

Idea → buildable plan (discovery)

[[product-discovery]]  (runs idea-shaping → product-brief → success metrics
→ RFC handoff → work-planning, gating on sign-off) → hand off to Build

New feature (full lifecycle)

[[product-discovery]] (or [[idea-shaping]]? → [[spec-first]]) → [[work-planning]]
→ [[incremental-delivery]] + [[test-first]]
→ [[browser-checks]] (if UI) → [[review-gate]]
→ [[launch-readiness]]

Bug fix

[[fault-recovery]] → [[test-first]] (regression test) → [[review-gate]]
→ [[skill-harvest]] (if the root cause was non-obvious)

Unattended / autonomous run

[[autonomous-loops]] (stop condition, maker/checker, circuit breakers, triage inbox)
+ [[long-running-agents]] (external state, checkpoints, compaction)
+ [[agent-verification]] (independent "done" check) → human reviews the batch before merge

Production incident

[[incident-response]] → (after) [[fault-recovery]] or [[decision-docs]] for follow-ups

New HTTP API

[[interface-design]] → [[test-first]] + [[incremental-delivery]]
→ [[contract-testing]] (if consumers deploy separately)
→ [[hardening]] → [[review-gate]] → [[launch-readiness]]

Breaking API/schema change

[[interface-design]] → [[migration-path]] → [[contract-testing]] (verify when old shape is safe to drop)
→ [[test-first]] → [[review-gate]] → [[launch-readiness]]

Slow checkout / page

[[perf-budget]] → [[react-patterns]] and/or [[data-modeling]] and/or [[caching-strategy]]

Implement Figma screen

[[design-handoff]] → [[ui-craft]] → [[accessibility]] → [[browser-checks]] → [[review-gate]]

Add npm package

[[dependency-hygiene]] → [[review-gate]]; justify vs own ([[simplify]])

LLM feature

[[spec-first]] → [[llm-feature-engineering]] → [[hardening]] → [[observability]] → [[review-gate]]

Product launch / go-to-market

[[launch-readiness]] (ship safely) → [[launch-campaign]]  (Grow conductor: runs
growth-strategy → community-engagement [seed before traffic] → seo-growth
→ content-marketing → social-distribution → email-nurture + referral-loop
→ growth-strategy weekly review, gating on the ordering rule)

5. Apply lifecycle order across phases

When a task spans phases, move top-down — don't jump to code if requirements are ambiguous.

Define → Plan → Build → Verify → Review → Ship → Operate → Grow

Finishing one phase points to the next — e.g. after Build + Verify, load [[review-gate]] before merge.

6. Load and follow — rules of use

1. If a skill matches, load and follow it — don't improvise a weaker version under time pressure.
2. Follow it fully — especially Verification checklists and anti-rationalization sections; partial application loses most value.
3. One primary skill at a time — secondary skills when the task touches their domain (see [[review-gate]] routing table pattern).
4. Read the skill's description — it's the trigger; if your task matches, trust it.
5. Chain, don't stack — finish [[spec-first]] before deep [[incremental-delivery]]; don't load all Build skills for a planning question.
6. Agents complement skills — code-reviewer with [[review-gate]], security-auditor with [[hardening]], test-engineer with [[test-first]]; the skill is still the process.

7. When no skill fits

If the task genuinely doesn't match anything:

• Proceed with sound engineering judgment
• Note the gap — recurring work without a skill → [[skill-harvest]] (triage) → [[skill-creator]] (author)
• After non-trivial work (tricky debug, repeated mistake, a skill that misfired), run [[skill-harvest]] to capture the lesson before context is lost
• Don't force-fit the wrong skill (e.g. [[simplify]] on an production incident)

Common Rationalizations

• "I know the process, I don't need the skill." — These skills encode steps people skip under pressure.
• "I'll load the skill after I start." — Wrong skill from minute one wastes the first hour.
• "Load everything so nothing is missed." — Context bloat; one primary skill per step ([[context-curation]]).
• "This is urgent, skip spec/plan." — Urgent bugs use [[fault-recovery]] / [[incident-response]]; urgent features still need a minimal spec when risk is non-trivial.
• "Review-gate covers it." — Review-gate routes to specialists; load [[hardening]] when the diff is auth-heavy, not only review-gate.
• "Any refactor skill will do." — [[simplify]] is behavior-preserving cleanup; [[migration-path]] is breaking change rollout — different jobs.

Red Flags

• Jumping to code on a vague one-liner with no [[spec-first]] or [[idea-shaping]] when scope is unclear
• Using [[fault-recovery]] for a production outage instead of [[incident-response]]
• Loading five skills and following none of them completely
• [[perf-budget]] skipped — optimizing by intuition
• UI change marked done without [[browser-checks]]
• Breaking API change without [[migration-path]]
• "I'll read the skill later" on a security or launch task
• Inventing a new review checklist instead of using [[review-gate]]

Verification

• Request classified by phase and primary intent
• Primary skill identified from the intent map (or disambiguation table)
• Lifecycle order respected — earlier phases not skipped when risk warrants them
• At most one primary skill loaded for the current step; secondaries only when domain requires
• Selected skill read and Process + Verification will be followed fully
• Next skill in the chain noted (e.g. after build → verify → review-gate)
• If nothing fits, gap noted for possible [[skill-creator]]