Add a primary "Use in chat" action to the skill detail. Clicking it leaves
the Skills surface, opens a fresh session in the current project, and seeds
the composer with the same structured skill chip the slash picker inserts
(`{ type: "skill", name, source: "skill" }`), routed via a new ?skill=
search param that the session bootstrap consumes.

Activation is therefore deterministic: the picked skill is the skill that
loads. This deliberately avoids a primed natural-language prompt, which would
fall back to the model matching the skill description and could load nothing,
the wrong skill, or a different one than the user clicked. Listing
(GET /skill) and activation (the skill chip) stay orthogonal: the gallery
reads from one, "Use in chat" writes through the other, adding no new
activation mechanism.

The ?skill= bootstrap reuses the existing generic route-prompt bootstrap
hook, so no new seam is introduced.

E2E (e2e/skills/skills-panel.spec.ts): the sidebar entry opens the gallery,
Escape closes the detail then the surface, and "Use in chat" opens a new
session with the summarize skill chip inserted (bare label, no leading
slash). Detail footer button reviewed in the refreshed skills-surface snap.

Opening a main-takeover surface (settings / automations / skills) from a
/session route that has the right utility panel open leaked the panel's
titlebar chrome over the surface: a 1px border-l divider, ~380px of reserved
rail width, and — under settings — the still-portalled tab strip ("Status").

Root cause: the right panel's titlebar chrome derived its visibility from
scattered, inconsistent conditions, none of which knew a surface was
covering the still-mounted session and its panel. titlebar's tabsRailActive
only checked `/session route && rightPanel.opened()`; right-panel-tab-strip
gated automations/skills but not settings. The prior fix only patched
session-header's two portals, so it missed the rail's own width/border-l and
the settings tab-strip leg — three separate chrome traces, one patched.

Fix: add a single source of truth `mainSurfaceOpen` to the shell-surface
context (derived from `activeSurface`), and have every piece of session
chrome a takeover covers read it: titlebar tabsRailActive, right-panel-tab-
strip, session-header's left/right portals (collapsed from the three-flag
form), and sidebar route-active suppression. Future surfaces only update the
one derivation.

`--right-panel-width` is left untouched on purpose: it is the panel's real
geometry, not a chrome-visibility flag. Zeroing it would animate the rail
0→380px on surface close against a body already at 380px (seam mismatch).
Only the rail's active state retracts.

Verified: new case in titlebar-right-rail-contract.spec.ts opens the right
panel then each of settings/automations/skills and asserts
#pawwork-titlebar-tabs has width 0, borderLeft 0px, 0 children — red before
(width 380), green after. Visually confirmed the divider and the settings
status-tab remnant are gone.

The skills gallery and "Use in chat" navigation resolved against the
owner project root (currentProject().worktree), mirroring the Automations
surface. But skills are directory-resolved capabilities, not project
entities: the composer's slash picker queries them against the active
route directory (the SDK directory). In a sandbox/workspace sub-route the
two diverge, so the gallery could list a different skill set than the
composer offers, and "Use in chat" dropped the user from their active
workspace into a root session.

Resolve skills against the active currentDir() like the composer does,
falling back to the project root only when no directory is active.

The gallery rendered the empty-state copy ("No skills match your search")
whenever filtered() was empty. While the resource is still resolving its
first batch, skills() is undefined and filtered() is empty, so every normal
load flashed "no skills" before the list appeared, and a load failure was
mislabeled as "no skills" with no way to tell the two apart.

Key the body off the resource state: a height-reserving placeholder while
loading (no flicker, no "Loading…" label since local skills resolve fast),
a dedicated message on failure, and the empty copy only once a real
filtered-to-zero result is in hand.

…session

Two independent route bootstraps seed the composer from ?skill= and ?prompt=.
The in-app entry points never set both ("Use in chat" sets only skill,
"Create via chat" only prompt), but a hand-built deep link could carry both,
and which one won was left to bootstrap definition order. Make the precedence
explicit — skill wins — so a combined link deterministically inserts the skill
chip instead of a text prompt.

The skill detail reader was a hand-rolled overlay: its own scrim, click-outside
close, stopPropagation, and role/aria-modal, plus a keydown listener on the
surface that sniffed the DOM for overlay components to decide whether Escape
should close the detail or the surface.

Mount it through useDialog().show instead, so the dialog base owns the modal
shell — overlay, focus trap, initial focus, focus restore, background inert,
Escape — and the detail only composes its content. The surface's Escape handler
now defers to a detailOpen() signal driven by the dialog's onClose (which fires
synchronously on close, unlike dialog.active, which lingers through the exit
animation), replacing the brittle DOM sniff. This also gives the reader the
correct full-window modal semantics its aria-modal already claimed.

Trade-off: the reader now covers the whole window (standard modal) rather than
only the surface region; accepted for the accessibility and consistency win.

…trap

The prior "skill wins" guard only stopped the prompt bootstrap from seeding
while ?skill= was still present. But the skill bootstrap cleared only the skill
param, which flipped that guard back off — the surviving ?prompt= then became
visible to the prompt accessor and re-seeded the composer a beat later,
overwriting the skill chip with plain text.

Clear both params when the skill is consumed so a combined deep link
(?skill=summarize&prompt=hello) deterministically lands the skill chip and the
stray prompt text never resurfaces.

…tail

The skills surface's Escape handler tracked only its own detail reader
(detailOpen), so Escape would wrongly close the surface when another modal was
up. That happens in practice: the sidebar stays live behind the surface, and its
search calls command.show() directly — bypassing the keybind gate that
suppresses ⌘K palettes behind a surface — so a command palette can sit on top of
the gallery.

Defer to dialog.active instead: the single source of truth for "a shared
dialog-stack modal owns Escape", covering both the detail reader and a
sidebar-opened palette, and replacing the old DOM overlay sniff. Trade-off:
dialog.active lingers through useDialog's ~100ms exit grace, so an Escape fired
within that window after a modal closes is absorbed rather than closing the
surface — negligible for a real user, and the e2e waits the grace out.

Adds regression tests: a palette opened over the gallery consumes Escape before
the surface, and the combined ?skill=&prompt= deep link seeds only the chip.

Two-up list rows now pair the humanized title with a two-line clamped
description, replacing the cramped single-line subtitle that packed the
band. The detail reader moves the frontmatter description into a bordered
cream summary card set apart from the SKILL.md body so the machine-facing
blurb no longer blurs into it, and drops the raw slug from the header —
it only echoed the humanized title and still shows in the footer path.
Removes the now-unused skillSummary passthrough.

- zh subtitle: use the 爪印 brand name (the established Chinese product
  name throughout zh.ts) and drop the "触发" jargon, per a DeepSeek-v4-pro
  copy review — was "PawWork 能做的事。…何时触发、如何工作。"
- en subtitle: name the antecedent ("Open a skill") and replace the
  "fires" jargon with "when it helps and how it works" (CodeRabbit)
- snap e2e: wait on observable state via expect.poll(...).toBeGreaterThan
  Equal and expect(locator).toHaveCount(0) instead of page.waitForFunction,
  matching the repo's E2E guideline (CodeRabbit)

The integrations settings description still read "PawWork" while every
other Chinese string uses 爪印. Also widen the branding test from a
five-key spot-check to a full scan of the dict, so a stray "PawWork"
can't slip back into any Chinese string unnoticed.