Motivation

Opening an issue or pull request is currently the only way to inspect its details from a list. When triaging or scanning many items, this loses the list context and makes quick comparison slower.

Add an explicit compact preview action so users can inspect the most important information without leaving the list. The existing title interaction must remain unchanged: clicking, middle-clicking, or Ctrl/Cmd-clicking the title continues to navigate normally.

Design

• Add a low-emphasis preview button beside each issue and pull request title, with the tooltip and accessible label Preview issue or Preview pull request.
• Open a read-only, non-modal drawer from the right on desktop.
• Show a summary rather than recreating the full detail page: title, reference, status, description, important metadata, and a limited amount of recent activity.
• Put prominent Open full issue/pull request, Previous, and Next controls inside the drawer, not in the issue or pull request list.
• Previous and Next navigate through the items in the current list order and update the drawer without closing it. At list boundaries, disable the unavailable control.
• If the adjacent item is unread, apply the existing .new visual treatment to its navigation control. The Previous control uses the normal left-side blue border. The right-aligned Next control uses a preview-specific variant with the blue border on the right so the indicator faces the outer edge. Do not change the generic .new styling globally.
• Opening or navigating within a preview must not mark an issue or pull request as read. Only opening the full item should retain the existing read-state behavior.
• Keep the first version read-only. Editing, workflow actions, PR diffs, and other complex operations continue to use the full page.
• On desktop, allow the drawer width to be resized within sensible minimum and maximum bounds and remember the width in the browser.
• On small screens, use a full-width, non-resizable sheet.
• Prevent the preview drawer and AI drawer from competing for space on narrow viewports; opening one closes the other.

Keyboard and focus behavior

• Escape closes the drawer and restores focus to the preview button that opened it, except when a focused text editor or nested interaction consumes Escape.
• For example, if an input, editor, autocomplete, dropdown, or other nested UI is active, the first Escape dismisses or exits that inner state without closing the drawer. A subsequent Escape may close the drawer once no nested state remains.
• Do not rely solely on a document-level Escape handler; nested components must be able to consume the event before drawer dismissal.
• The preview action and all drawer controls must be keyboard accessible and available on touch devices, not hover-only.

Implementation direction

Create or extract a reusable right-side drawer shell from the existing AI drawer mechanics, including resizing, persisted width, responsive behavior, focus restoration, and coordination between drawers.

Roll out issue previews first, reusing suitable issue display components in a read-only composition. Use that experience to settle the shared drawer API before adding the more page-oriented pull request preview.

Acceptance criteria

1. Titles retain all existing navigation behavior.
2. A separate accessible action opens the compact preview.
3. Open full item, Previous, and Next controls appear inside the drawer.
4. Previous and Next follow the current list ordering and correctly indicate unread adjacent items, including the right-border treatment for Next.
5. Previewing does not clear unread state.
6. Escape honors nested text/editor interactions before closing the drawer, and drawer closure restores focus to its trigger.
7. The drawer is resizable and width-persistent on desktop, full-width on small screens, and does not conflict with the AI drawer on narrow viewports.
8. Issue preview is delivered first; pull request preview follows using the shared drawer abstraction.