Imported from mthines/lorekit (.claude/skills/command-coverage/SKILL.md). Install upstream with npx skills add mthines/lorekit --skill command-coverage. Copyright stays with the author (MIT).

Command Coverage

Ensures every place a user can navigate to and every action they can take in packages/web is exposed consistently in two surfaces:

1. The command palette (⌘K / Ctrl+K), and
2. A keyboard shortcut that follows Linear's conventions.

The skill crawls the web app, builds two inventories (what exists vs. what is registered), diffs them into a coverage matrix, recommends a Linear-style binding for each gap, and — in apply mode — writes the missing useCommand({...}) registrations behind a confidence gate. It reads and writes LoreKit memory so the approach (conventions, decisions, prior gaps) compounds across runs.

This SKILL.md is a thin index. The crawl procedure, the Linear key map, the auto-wire mechanics, the LoreKit protocol, and the concrete palette API contract live in rules/*.md and references/*.md — load only what the current phase needs.

Mode Detection

Parse $ARGUMENTS. First token selects the mode; --scope narrows the crawl.

--scope (default all): dashboard (routes + actions behind auth), docs (the public /docs palette), blog (the public /blog palette), or all.

State the detected mode and scope in one line before continuing:

Mode: audit
Scope: all

apply runs the full audit pipeline first — it never wires blind.

Workflow

audit stops after Phase 4 and still runs Phase 6. apply runs all phases.

Required Reading by Phase

Load on demand — do not preload.

The concrete packages/web palette contract (the Command type, the useCommand hook-position rules, existing bindings, id-prefix conventions) lives in references/palette-api.md. Read it before crawling or wiring so the skill never re-derives — or drifts from — the real API.

Report format (Phase 4)

Emit one coverage matrix, then the recommendations. Group by surface scope.

## Coverage — dashboard

| Target / action        | Route / trigger  | Palette | Shortcut | Warrants shortcut? | Gap  | Proposed shortcut | Proposed palette      | Prio |
| ---------------------- | ---------------- | ------- | -------- | ------------------ | ---- | ----------------- | --------------------- | ---- |
| Overview               | /overview        | ✅ nav-overview | ✅ g o | yes            | —    | —                 | —                     | —    |
| Lore Explorer          | /lore            | ✅ nav-explorer | ✅ g e | yes            | —    | —                 | —                     | —    |
| Settings → Plan        | /settings/plan   | ✅ settings-plan | ❌   | no — occasional | —    | —                 | —                     | —    |
| Filter (Explorer)      | FilterMenu open  | ❌      | ❌       | yes                | both | `f`               | "Filter lore…" (Lore) | P1   |
| Focus search (Explorer)| search input     | ❌      | ❌       | yes                | both | `/`               | "Search lore…" (Lore) | P1   |
| Keyboard help          | (none)           | ❌      | ❌       | yes                | both | `?`               | "Keyboard shortcuts…" | P3   |

Rules for the matrix:

• One row per navigation target AND per page-level action.
• Palette cites the registering command id when present, ❌ when absent.
• Shortcut cites the key sequence when present, ❌ when absent.
• Gap is frequency-aware, one of:
  • — covered — has a palette entry, and either has a shortcut or does not warrant one (occasional/destructive/deep). A palette-only settings page is —, NOT a shortcut gap.
  • palette — missing its palette entry (always a real gap; the floor).
  • shortcut — passes the shortcut test but has no shortcut.
  • both — missing the palette entry AND warrants a shortcut.
• Include a Warrants shortcut? judgment per row (yes / no — occasional / no — destructive / contextual) so a palette-only row reads as a decision, not an oversight.
• Proposed shortcut / Proposed palette — the suggested binding for a gap row (from rules/linear-shortcuts.md), or — for a covered row. Every gap row MUST carry a proposal so the user can challenge each one individually. When a proposal is blocked (e.g. a handler must be lifted first, or a token collides), append the blocker inline — e.g. `f` ⚠ lift FilterMenu handler or `g o` ✗ taken → `g m`.
• Prio is P1–P4 (P1 = high-frequency, both surfaces missing).
• Never invent coverage: a target counts as covered only if a real useCommand registration is found in the crawl (Phase 1).
• The separate prose "Recommendations" list is now redundant with the Proposed* columns — keep only cross-cutting notes (new features, ordering) below the table, not per-row repeats.

Core Principles

1. Palette is the floor; a shortcut is earned. EVERY navigable target and real action gets a command-palette entry — that is the discoverability baseline and its absence is always a gap. A keyboard shortcut is the accelerator layer, added ONLY when the target passes the shortcut test (frequent + global + flow-critical — see rules/linear-shortcuts.md). A low-frequency destination with a palette entry and no shortcut is correctly covered, not a gap. Shortcuts are a scarce, memorable resource — spending one on a rarely used page devalues the whole keymap.
2. Follow Linear, do not invent. g prefix is reserved for navigation; single letters (F, L, C, …) are context actions; ⌘K opens the palette. Reuse the repo's existing bindings before adding new ones.
3. Table-driven truth. Navigation is already driven by DOCS_SECTIONS, SETTINGS_SECTIONS, and BLOG_SECTIONS; register from those tables, never a hand-copied list that can drift.
4. Never wire blind. apply only writes after the audit matrix and a confidence ≥ 90% gate; show the diff and get explicit user confirmation.
5. Compound the approach. Read LoreKit at the start, write decisions and newly-found conventions at the end, so the next run is smarter.

Anti-patterns

• Registering commands inside a .map() — breaks React hook order. Wrap each item in its own component (see the DocsCommandItem pattern).
• Reusing a key token already bound (checked against the live registry).
• Binding a single-letter action that fires globally without respecting the input/textarea/contenteditable guard.
• Claiming a target is covered from the route table alone without finding its useCommand registration.
• Adding a nav command with a g-prefix that collides with g o/e/s/g.

Definition of Done

• Mode + scope stated in one line.
• LoreKit recalled (Phase 0) and recorded (Phase 6).
• Coverage matrix covers every route, section-table entry, and page action.
• Every gap has a proposed Linear-style binding with no token collision.
• apply only: each new registration passed the confidence gate, the user confirmed, and pnpm nx typecheck web is green.
• One-line summary of the coverage delta delivered to the user.