Shipped: keyboard-first KB search
A small thing that power users have been asking for since month three. Keyboard-first KB search with a reachable command palette, typed result filtering, and no mouse required to open, navigate, and act on a chunk.
Keyboard-first KB search shipped this week. The feature has been on the backlog since about month three — long enough that the request acquired a small dedicated thread in customer support — and finally cleared the queue behind the higher-priority work. The underlying search surface is the same one the Knowledge Base page describes; this ship is the keyboard layer over it.
The behavior is what you would expect.
Cmd-K (or Ctrl-K on Windows and Linux) opens the command palette from anywhere in the app. The palette focuses a search input by default and runs incremental search against the KB as you type, with the same retrieval logic the drafter uses. Results show the chunk title, the source document, the last-updated date, and the first line of the chunk content.
Tab and Shift-Tab cycle through filters — source, vertical, authority level, recency — with each filter applying a query refinement without closing the palette. Arrow keys navigate results. Enter opens the selected chunk in a reading pane that is itself keyboard-navigable. Cmd-Enter inserts a citation-anchored reference to the chunk into the active draft. Esc closes everything back to where you started.
The two power-user features that took the most work to get right:
Filter chips render as keyboard-reachable elements. Early builds treated the filter row as decoration and made it mouse-only. Accessibility review flagged that correctly; the final version walks the filter chips with Tab the same way the results list walks with arrow keys.
The reading pane does not steal focus from the palette input. You can read a chunk, decide it is wrong, and keep typing to refine the search without having to re-click the input. This sounds obvious. It took three revisions to get the focus model right.
The feature is live for all customers on all plans. Documentation is updated; the shortcut reference page now lists every keyboard command in the app. If you are a power user and you find a workflow that still forces a mouse, send us the specifics and we will fix it.
One small implementation note for anyone building a similar surface. The hardest part of a command palette is not the search; it is the focus management around the palette itself. A palette that gets modal-dialog semantics wrong will trap screen readers, break back-button behavior on some browsers, and interact badly with tab-bar shortcuts at the OS level. The accessibility review that caught the filter-chip issue also caught three smaller focus-management issues that a developer iterating without a review would have shipped. Screen-reader testing is worth the time.
A second note. We gated the Cmd-K shortcut so that it does not conflict with the same shortcut in common embedded contexts (the in-app docs viewer, the editor in a drafting pane). When those surfaces are focused, Cmd-K routes to their local handler instead of the global palette. That is the correct behavior and also the behavior that is easiest to get wrong. Test every embedded surface.
The backlog has two more keyboard-first items queued for the next cycle: tabbable review pane and a “go to section” palette for navigating long drafts. Both should ship in the next few weeks.