Which Skill

---
name: which-skill
description: >-
  Router over the feature-flow kit — given a situation in plain words, recommend which kit
  skill (or short chain of skills) fits, and why. The map of the kit and the
  discover→analyst→prepare→implement flow, so you don't have to remember 20+ skills.
  TRIGGER when: the user asks "which skill should I use for…", "what's the right flow for…",
  "where do I start", "is there a skill for X", or describes a situation without naming a skill.
  TRIGGER ALSO (silent match) when the user states a concrete task and names no skill: a
  task-shaped request is not evidence that no skill fits, so check the catalog before running
  bare. Answer in one line and hand off — see "Silent match" below.
  DO NOT TRIGGER when: the user already named the skill they want (just run it).
allowed-tools: Read, Glob, Grep, AskUserQuestion
effort: low
---

# Which Skill?

Point the user at the right skill for their situation. Read what they're trying to do, match it to
the catalog below, and recommend the skill — or a short chain — with a one-line reason. When the
situation is genuinely ambiguous between two skills, ask one focused `AskUserQuestion` to
disambiguate; otherwise just recommend and offer to start it. If `/which-skill` is invoked with
no situation described, first ask the user what they're trying to do, then route.

## Silent match — when nobody asked for a router

You also fire on plain task requests that name no skill. That path must stay nearly free, or it
taxes every prompt:

- **One obvious match** → one line (`This is /close-epic — <reason>. Run it?`), then run it if the
  user agrees or the task is clearly the skill's own job. No catalog, no map, no phase list.
- **Two candidates** → one `AskUserQuestion`, two options.
- **No clear match** → say nothing about routing and do the work bare. A silent miss costs
  nothing; a paragraph about skills the user didn't ask for costs a turn.

Never make the user re-state the task after routing — carry it into the skill you name.

> **Maintenance:** every user-facing workflow skill should appear both here and in the kit repo's
> `guide/*/reference.md` "What's in it" table — keep the two in sync when a skill is added or removed. (This catalog
> deliberately omits `/which-skill` itself and the on-demand stack pack-reference skills like
> `/ruby-idioms`, so the two lists aren't byte-identical.) If unsure the list is current, `Glob`
> `skills/*/SKILL.md` and reconcile. Adding a skill the *model* may reach unprompted (no
> `disable-model-invocation`) also spends the shared skill-listing budget — check it against the
> caps in `skills/writing-skills/SKILL.md` § Platform caps on authoring before dropping the flag.

---

## First, the tier — how big is the thing they're holding?

Before picking a skill, size the input. Three tiers, three entry points; the routing mistake
this table prevents is pointing `/prepare` at a whole surface.

| Tier | The user is holding | Route to | Output |
|---|---|---|---|
| **1 · Program** | a whole *surface* to audit or map — "review every screen", "audit this area", output is plausibly 10+ separate pieces of work | **`/prompt-master`** (program pass) | ranked `00-report.md` + `evidence/` + `cards/NN-<slug>.md` + `RUN-ORDER.md`, stopping before any implementation |
| **2 · Epic** | one card, or one coherent change | **`/prepare`** | `00-overview.md` + `NN-<subtask>.md` in file-disjoint waves |
| **3 · Session** | one prepared subtask | **`/implement`** | code + implementation log + deviation report |

Tier 1 hands off to tier 2 one card at a time (`/prepare <program>/cards/NN-<slug>.md`).
A tier-1 pass never writes plans, and `/prepare` never authors a program.

## The pipeline (the spine)

```
/discover → /analyst → /prepare → /implement
research    spec        plan        build
```

- **`/idea`** — the plain-language front door *over* the spine, for a non-technical user (or
  anyone who just wants to describe an outcome): elicits the wish in outcome scenarios,
  shows 2–3 solution shapes with felt trade-offs, then drives the whole pipeline itself —
  owning every technical decision and reporting back in behavior terms.

- **`/discover`** — research prior-art & reuse before committing; scope a fuzzy idea. Read-only;
  writes a brief.
- **`/analyst`** — turn a raw idea into a spec via a structured interview (wraps `/grill`). Answers
  WHAT and WHY.
- **`/prepare`** — pre-implementation analysis: design alternatives, impact, SOLID/DRY,
  decomposition into parallel-safe execution waves. Answers WHETHER-READY and HOW.
- **`/implement`** — execute a prepared plan with deviation tracking, an architecture audit, and
  tests; every finding it hits is routed down one of four branches (fix · file a card · STOP and
  ask · hand to the sibling that owns the file), and the behavior check drives *this* slice only.
  May delegate a slice to `/tdd`.
- **`/scaffold`** — add a new module/component/command *modelled on an existing one*: exemplar
  first, placement from the profile, then every registration point wired and **proved by a
  command**. Use it when the artifact has to be registered somewhere to exist at all; a plan-sized
  change is still `/prepare`, a known edit is still `/implement`.

## Alignment & design (primitives the pipeline reuses)

- **`/grill`** — relentless one-question-at-a-time interview to pressure-test *any* plan before
  building. Standalone or invoked by analyst/prepare/spike/arch-health.
- **`/grill-with-docs`** — a grilling session that *also* builds the shared language: runs `/grill`
  while `/domain-model` records terms + ADRs inline. The high-leverage "align and document" combo.
- **`/domain-model`** — build the living glossary (`CONTEXT.md`) + ADRs; pin down terminology,
  record a decision. Run it alongside grilling to capture terms.
- **`/codebase-design`** — deep-module design vocabulary (small interface, big implementation,
  seams). Reach for it when designing or improving a module's interface.

## Explore a design before committing

- **`/spike`** — validate ONE risky hypothesis, yes/no, time-boxed, throwaway. *"Can X even do Y?"*
- **`/select-tech`** — choose a library/gem/framework/service (or decide to build it): hard
  filters → issue-tracker + hard-case probe on 2–3 finalists → scored matrix, ONE
  recommendation, adapter-seam integration contract. *"What should we use for X?"*
- **`/prototype`** — EXPLORE a design space: a runnable logic prototype, or several UI variations to
  compare. *"How should this look/behave?"* Many options, not one answer.

## Build & verify

- **`/onboard`** — fast comprehension of an *unfamiliar* codebase: run-it-first, one traced
  end-to-end flow, git-history archaeology (churn hotspots, bus factor, feared-old code),
  load-bearing-weirdness list → a written orientation map. Feeds `/bootstrap`.
- **`/api-design`** — design a public contract (endpoint/webhook/CLI/library API) before
  building: consumers & compatibility promise, resource model in domain language, the
  contract checklist (errors, pagination, idempotency, versioning), worked examples incl.
  errors, consumer's-eyes review. Internal seams stay with `/codebase-design`.
- **`/threat-model`** — design-time STRIDE-lite over a spec/plan that adds external surface:
  entry points × trust boundaries × forgotten actors (unauthenticated, wrong-tenant), abuse
  cases; every threat lands as an AC, plan step, or user-signed accepted risk. Post-build
  audits stay with `/audit-security`.
- **`/perf`** — measurement-first optimization: budget & metric → reproducible baseline →
  profile finds the real hotspot → biggest lever first, one change per re-measure → stop at
  the budget. Never optimizes unmeasured code.
- **`/tdd`** — drive new code test-first, red-green-refactor, vertical slices.
- **`/test`** — author tests for existing code, or audit/refactor a test suite.
- **`/test-spec`** — spec-first tests derived from a plan/spec *without reading the code*, so the
  spec is the source of truth (a failing test means the code is wrong). Sits between `/tdd` (no
  written spec) and `/test` (reads the module).
- **`/diagnose`** — root-cause a specific bug: reproduce → isolate → fix → verify.
- **`/code-review`** — review changed code for correctness/security/performance + conventions
  (review-only, no fixes).
- **`/refactor`** — apply quality cleanups to changed code (same behaviour), then format + test.
  The pair mirrors the built-in taxonomy: `/code-review` hunts **bugs**, `/refactor` (the kit's
  counterpart of the built-in `/simplify`) does **quality only** — route by which of the two the
  user actually wants, and never both for the same class of finding.
- **`/audit-quality`** — scoped architectural audit of a module or changeset: each file
  SOUND / SHORTCUT / HACK against *this* codebase's layer map and canonical patterns, behind an
  evidence gate (git log, callers, sanctioned exceptions, prior decisions) — plus a phased
  refactor plan with bugs split into Phase 0. *"Is this a hack or is it sound?"* Where
  `/code-review` hunts **defects in a diff** and `/arch-health` ranks debt across the **whole
  repo**, this one judges the **design of a scoped area**.
- **`/arch-health`** — periodic whole-codebase scan for shallow modules & ball-of-mud hotspots;
  ranks deepening opportunities and routes them.
- **`/clean-mvp`** — whole-codebase cruft sweep: dead code, unused files, legacy shims — with a
  proof-of-deadness evidence gate and batched delete confirmations.
- **`/sweep`** — mass mechanical migration across many files (rename an API, swap a library):
  complete site inventory → pilot batch → batched transform with per-batch verification → a
  zero-leftover re-scan; at ~30+ mechanical sites it writes an AST-based codemod instead of
  hand edits. Changes *live* things; `/clean-mvp` removes *dead* things.

## Architecture evolution (revisit what's built)

- **`/decompose`** — monolith vs modular monolith vs extracting a service, decided per
  boundary on evidence (real drivers vs the distributed tax; org facts asked, never
  guessed). Verdict STAY / MODULARIZE / EXTRACT, recorded as an ADR; extraction executes
  via `/rollout`. Governing rule: extract the seam before the service.
- **`/revisit`** — re-audit past decisions (ADRs, tech picks, undocumented load-bearing
  choices): extract each decision's assumptions, test them against today's reality
  (internal + live external research), verdict HOLDS / STRAINED (tripwire) / BROKEN
  (reopen → `/select-tech`, `/prepare`, `/decompose`). Assumption audit, not preference
  audit — no drive-by relitigation.
- **`/distill`** — mine the codebase's implicit conventions (error handling, construction,
  data access, test shape…), verdict each BLESS / UNIFY / BAN / DEEPEN with cited
  occurrences, install the verdicts as project rules / `CONTEXT.md`; migrations route to
  `/sweep`. Makes generated code copy the *best* pattern in the repo, not the most
  frequent one.

## Ship & learn

- **`/rollout`** — design the *strategy* for shipping a risky/irreversible change: expand-contract,
  strangler fig, feature flags / canary, versioned coexistence — a staged plan where every stage
  is deployable, verifiable, and reversible alone. *"How do we ship this safely?"*
- **`/deploy`** — *which* deploy command this change actually needs: classify the working tree
  against `PROJECT.md` → Deploy mapping, then name the **cheapest sufficient** command with its
  cost (a config edit does not buy a 5-minute rebuild), plus the post-deploy verification
  checklist and the rollback line. "No deployment needed" is a real answer. Commands are handed
  over as text, never run. Strategy for a risky change stays with `/rollout`.
- **`/preflight`** — release-readiness gate before shipping: full suite + lint, dependency &
  security quick pass, docs drift, config/migration check, behavior spot-check, changelog
  draft, and a GO / GO-WITH-RISKS / NO-GO verdict (deploy command suggested, never run).
- **`/incident`** — production is broken *right now*: triage → preserve evidence → mitigate toward
  known-good (rollback / flag off) → verify recovery → blameless review. The live-fire inversion
  of `/diagnose` (stabilize first, understand later); commands suggested, never run.
- **`/retro`** — the learning loop: mine archived plans' Deviation Reports, handoffs, and
  diagnose/arch-health reports for *recurring* patterns (≥2 cited occurrences, verified), then
  fold each confirmed lesson back into rules / PROJECT.md / CONTEXT.md / skills — with
  confirmation. Run after an epic or a rough week.

## Backlog & docs (local issue tracker)

- **`/to-prd`** — synthesize the current conversation into a PRD (no interview).
- **`/to-issues`** — break a plan/PRD into independently-grabbable vertical-slice issues (local
  files).
- **`/triage`** — move backlog issues through the triage state machine; answer "what's next".
- **`/epic-status`** — read-only dashboard over a wave-structured decomposition from `/prepare`:
  progress per wave, the next safe wave to launch, session-collision check, and the epic's
  `RUN-ORDER` read against the plans themselves — a `∥` mark is a claim, re-verified against the
  `Owns` sets, and any drift is reported rather than quietly fixed. Never writes.
- **`/close-epic`** — the terminal counterpart of `/epic-status`: verify every plan is terminal,
  then run the epic end-to-end — its declared `## E2E verify` block, or a battery *derived* from
  the surfaces the diff touched and disclosed as derived (drives delegated, verdict kept, one
  headline number re-derived by hand) — then plan↔code conformance + docs drift, a completeness
  critic, a **surface↔profile check in both directions** (dangling refs, *and* what the epic added
  that `PROJECT.md` / the rules / the docs never learned), small documentation debt fixed inline,
  pricing of every flagged follow-up against a closed list of consequence classes (default: a named
  known-undone clause, **not** a card) with only the survivors promoted into a **runnable board**
  (`<topic>-followups/` — cards + routed session prompts + RUN-ORDER, packed to the session context
  budget) and only when the open-debt stock allows a new one, a predicted-vs-actual ledger row, `## E2E
  results` written back into the epic overview, and a copy-paste archive command it never runs.
  **Takes a batch** — several epic paths in one invocation close per-epic under one agent budget.

## Security & dependencies

- **`/deps`** — dependency & vulnerability audit; proposes a safe upgrade path (propose-only).
- **`/audit-security`** — orchestrating OWASP-style security sweep that ties together the security
  rule, `/security-review`, the `security-reviewer` agent, and `/deps` into one risk-tiered report
  with a deploy verdict. (For a diff/PR-level check, use the `security-reviewer` agent directly.)

## Session & kit lifecycle

- **`/handoff`** — snapshot live state (done · next · decisions · files · how-to-verify) into a
  resume doc before a reset or handoff.
- **`/bootstrap`** — the front door: first install on a fresh project. On a project that's already
  adapted it hands off to `/update-kit` (never re-copies over your edits).
- **`/update-kit`** — any adaptation after the first install — a newer kit version *or* a re-adapt
  after structural changes. Stages the kit, 3-way merges (keeps your adaptations), re-adapts inline.
- **`/teardown`** — clean up kit leftovers or uninstall and restore.
- **`/prompt-master`** — compile an idea into a phased pack of self-contained, copy-paste
  prompts (research → spec → plan → implement → verify) to run in *other* sessions or with
  Opus/Sonnet-class models — instead of doing the work here and now. Also the **tier-1 home**:
  it authors the program pass (one orchestrator prompt, fan-out per phase, evidence files, a
  kill phase, then report + cards + RUN-ORDER — stopping before implementation), and emits a
  `Workflow` script for a deterministic pack. Emitted, never run: launching a workflow is the
  user's opt-in.
- **`/writing-skills`** — *(kit-internal)* reference for authoring new kit skills.

---

## Matching guide (situation → route)

| The user says / wants… | Route |
|------------------------|-------|
| "Build a feature (start to finish)" | `/discover` → `/analyst` → `/prepare` → `/implement` → `/code-review`+`/test` |
| "I just want it so that… / user is non-technical / хочу вот так" | `/idea` (fronts and drives the whole pipeline in plain language) |
| "I have an idea but it's fuzzy" | `/discover` → `/analyst` |
| "Research / find out about X" | `/discover` (chains global `/deep-research` for open questions) |
| "Gather requirements / write a spec" | `/analyst` |
| "Poke holes in my plan / grill me" | `/grill` |
| "Grill me and write down what we decide" | `/grill-with-docs` |
| "What do we call this thing / our terms are a mess" | `/domain-model` |
| "Plan this before I build it / decompose it" | `/prepare` |
| "Build this approved plan" | `/implement` |
| "Add another module/command/adapter like the existing one" | `/scaffold` (exemplar + registration proved by command) |
| "Can X even do Y?" (one yes/no risk) | `/spike` |
| "Which library/gem/service for X / build or buy?" | `/select-tech` (then `/spike` if the winner carries a bet) |
| "Mock this up / which design looks better" | `/prototype` |
| "Build it test-first" | `/tdd` |
| "Add/clean up tests for existing code" | `/test` |
| "Test this against the spec / the plan says X" | `/test-spec` |
| "There's a bug / it's broken" (dev/CI, no live users bleeding) | `/diagnose` (then `/tdd` or `/test` to lock the fix) |
| "Production is down / users are hit RIGHT NOW" | `/incident` (mitigate first) → `/diagnose` (root cause after) |
| "How do we ship/migrate this safely / zero-downtime / feature-flag it" | `/rollout` (staged strategy) → `/prepare` → `/implement` per stage |
| "Review my changes / this PR" | `/code-review` |
| "Tidy / simplify / de-dup this code" | `/refactor` |
| "Where's the tech debt / what's rotting" | `/arch-health` |
| "Monolith or microservices / should we split X into a service" | `/decompose` (→ `/rollout` on EXTRACT) |
| "Is X still the right choice / we decided this long ago / why do we even use Y" | `/revisit` |
| "Make the code consistent / extract our conventions into rules / what patterns do we have" | `/distill` (unification → `/sweep`) |
| "New/inherited repo — разберись, как это устроено" | `/onboard` (then `/bootstrap` to write the profile) |
| "It's slow / optimize / reduce latency-memory" | `/perf` (budget → baseline → profile → fix → re-measure) |
| "Design this endpoint/webhook/public API" | `/api-design` (→ `/threat-model` if surface is external) |
| "What could go wrong security-wise with this design" | `/threat-model` (pre-code; existing code → `/audit-security`) |
| "Sweep out dead code / unused files / legacy shims" | `/clean-mvp` |
| "Rename/replace X everywhere / migrate all call sites / swap this library" | `/sweep` |
| "Are we ready to ship / release / deploy?" | `/preflight` |
| "What keeps going wrong / learn from the last epic / post-mortem" | `/retro` |
| "How should I design this module's interface" | `/codebase-design` |
| "Write up what we decided" | `/to-prd` |
| "Break this into tickets/work items" | `/to-issues` |
| "What should I work on next / sort the backlog" | `/triage` |
| "Where is this epic / what's the next wave / can I run these in parallel" | `/epic-status` |
| "This epic's done — settle and archive it" (one epic **or a list of them**) | `/close-epic` |
| "Turn what the close-out found into an epic with cards/prompts so we can finish it" | `/close-epic` (Phase 5b authors the board) — **not** `/prepare`, which takes one card at a time |
| "Are my dependencies safe" | `/deps` |
| "Security audit before deploy / full security sweep" | `/audit-security` |
| "I need to stop / hand this off" | `/handoff` |
| "Generate prompts for this idea / a prompt pack to run later or with another model" | `/prompt-master` |
| "Audit this whole surface / review every screen / map all of X and tell me what to fix" | `/prompt-master` (tier-1 program pass → cards) → `/prepare` per card — **not** `/prepare` on the surface |
| "Set up / remove the kit" | `/bootstrap` / `/teardown` |
| "Update the kit / pull a newer kit version" | `/update-kit` |

If the situation spans several rows, recommend the **chain** (e.g. *"`/diagnose` to root-cause,
then `/tdd` to lock it with a failing test"*) and offer to start the first step.

---

## End-to-end flows (when the situation is a whole journey, not one step)

When the user describes a **goal** rather than a single task ("build a feature", "refactor this",
"research X"), give the **whole route A→Z**, say where they are on it, and offer to start the first
step. Each kit skill also routes onward at its own end, so the flow self-propels — the user
confirms each handoff; nothing runs the whole pipeline silently.

- **Build a feature:** `/discover` → `/analyst` → `/prepare` → `/implement` → `/code-review` +
  `/test`. Run `/domain-model` alongside to capture terms/ADRs. Known/small change → start at
  `/prepare` or `/implement`; still fuzzy → `/grill-with-docs` first.
- **Research something:** `/discover` (repo prior-art & reuse; chains the global `/deep-research`
  for open external questions) → `/analyst` to turn findings into a spec.
- **Refactor / clean up:** *changed code* → `/code-review` → `/refactor`; *whole-codebase rot* →
  `/arch-health` → `/refactor` (small) or `/prepare` → `/implement` (large). `/codebase-design` is
  the shared vocabulary.
- **Requirements → backlog:** `/grill-with-docs` → `/analyst` → `/to-prd` → `/to-issues` → `/triage`.
- **Fix a bug:** `/diagnose` → `/tdd` or `/test` (lock it with a regression test).
- **De-risk a design:** `/spike` (one risk) or `/prototype` (compare options) → back into the pipeline.
- **Ship it:** `/close-epic` (settle the epic's plans) → `/preflight` (release gate: suite,
  deps/security, docs drift, changelog, GO/NO-GO) → deploy command from `PROJECT.md` (you run it).
  A risky/irreversible change gets a `/rollout` strategy *before* this — each stage then ships
  through the gate.
- **Production fire:** `/incident` (triage → preserve evidence → mitigate → verify recovery) →
  `/diagnose` (root cause) → `/tdd`/`/test` (regression test) → `/retro` if it's a repeat offender.
- **Learn from it:** `/retro` after an epic or a painful stretch — recurring lessons flow back
  into rules/profile so the same thing doesn't go wrong a third time.
- **Migrate mechanically:** `/sweep` (inventory → pilot → batches → zero-leftover re-scan);
  if judgment sites dominate, it's really a redesign → `/prepare` → `/implement`.
- **Audit a whole surface (tier 1):** `/prompt-master` authors the program pass (breadth sweep →
  lens passes → probes → adversarial kill → ranked report + cards + RUN-ORDER) → the user picks
  cards → `/prepare` per card → `/implement` per wave → `/close-epic`. The pass itself stops at
  cards; nothing is implemented from the report.

Pick the flow that matches, render it with the user's current position marked, and start step one.

---

## Hard rules

- **Recommend, don't run silently.** Name the skill (or chain) and the reason; let the user start it.
- **One disambiguation question max.** If two skills genuinely fit, ask once; otherwise just route.
- **Don't invent skills.** Only route to skills that exist in the catalog (or a global built-in
  like `/deep-research`); if unsure the list is current, `Glob` `skills/*/SKILL.md` and reconcile.
  If nothing fits, say so and suggest the closest manual approach rather than inventing a `/skill`.
- **Stay in sync.** Every user-facing workflow skill appears here and in the kit repo's
  `guide/*/reference.md` — update both when the set changes (the router need not list itself or the pack-reference skills).

## See also

- **`/writing-skills`** — when the user wants to *add* a skill, not pick one.
- `guide/en/reference.md` (kit repo) — the same catalog in table form, kept in parity with this one.