Thanks for the thoughtful proposal. I agree with the core interaction: clicking the title should continue to open the item normally, while a separate, explicit action opens a preview.

No clarifying question is needed for the initial UX direction. My recommendation is:

From the current implementation, this is feasible with substantial reuse, but I would describe a polished issues-and-PRs version as a moderate change rather than “minimal new code”:

• The AI chat already demonstrates the useful mechanics: a fixed right-side panel, a draggable left edge, a minimum width, and persisted width. Those mechanics should be extracted or generalized into a reusable drawer shell instead of coupling previews directly to the chat component.
• Issue boards already have a composed issue-detail modal built from reusable issue panels. That is a useful starting point, although it is currently tailored to the board modal and includes editing/full-detail behavior that a preview should probably omit.
• Pull-request detail is more page-oriented and does not have an equivalent compact detail component, so supporting PR previews cleanly will require more refactoring than issue previews.
• The list row components already distinguish the main title link, so a separate preview action can be added without changing Ctrl/Cmd-click, middle-click, or ordinary navigation.

For a superior UX, I suggest these details:

• Keep the title as the primary navigation target. Use a low-emphasis preview icon with the tooltip and accessible label “Preview issue” or “Preview pull request.”
• Do not make the action available only on hover; it must remain discoverable by keyboard and touch users.
• Make the drawer non-modal on desktop so users retain list context. Support Escape to close it and restore focus to the button that opened it.
• Allow resizing only on desktop, with sensible minimum and maximum widths, and remember the chosen width in the browser. On small screens, use a full-width, non-resizable sheet.
• Include an obvious Open full issue/PR action. Optionally add previous/next controls once the basic interaction proves useful.
• Keep the first version read-only and summary-focused. In particular, PR diffs and complex operations should continue to open on the full page.
• Avoid showing the preview drawer and AI drawer side by side on narrow viewports; opening one should close the other.

A practical rollout would be issue preview first, using the existing issue components to validate the interaction, followed by a shared drawer abstraction and then PR preview. This gives us user feedback before taking on the more coupled PR detail refactor.

I choose option number one: Compact right-side preview (your recommendation)

Support Escape to close it and restore focus to the button that opened it.

The only exception to this is that if a text box is highlighted and the user presses Escape, it should escape the text box rather than closing the drawer. If I'm not mistaken, I believe this intent is already reflected in the current code.

Include an obvious Open full issue/PR action. Optionally add previous/next controls once the basic interaction proves useful.

I really like the idea of this. Just to confirm, you're talking about this within the drawer, correct? Not in the issues or PR list? The previous/next controls will be very useful. I think it's important to have the .new class for the left and right arrows if the previous or next issue/PR is unread. This is definitely correct for the previous control. The next control should have its new class customized so that the additional border is on the right-hand side (blue border-right) instead of the left (blue border-left), making it fluent to the eye. This is because the next control would be right-aligned, so the visual aspect of the blue border peeking out on the right-hand side would make more sense.

Since we are in preview mode, entering preview mode should not get rid of the new flag on the issue/PR.

Keep the first version read-only and summary-focused. In particular, PR diffs and complex operations should continue to open on the full page.

Happy with this. This behavior is in alignment with the above-mentioned comment about not removing the new flag.

Avoid showing the preview drawer and AI drawer side by side on narrow viewports; opening one should close the other.

Yes, this is very important.

@servicedesk don't create a new issue yet. Please create a new comment, which would be the description of the new issue, and create the new issue only if @robin is happy. The reason for creating the new issue is to confirm design decisions. Ensure that it includes the motivation and design decisions from this issue and is able to stand alone with all the required information.

@robin, please review the following proposed issue description and confirm whether the design is suitable. Per @zaakiy's request, I have not created the issue yet.

Add compact previews for issues and pull requests

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.