Code Review Inbox App Design

Code Review Inbox Structure

This desktop-app design presents a GitHub review-request and mention inbox as a vertically ordered workspace. A left rail begins with “All 5,” followed by “Participating,” “Mentions,” and “Review requests 2.” The main column then groups work into review requests, CI checks, assigned issues, and activity. That sequence turns several engineering signals into one scan path, while the separate categories preserve enough context to decide what needs attention first.

A Review Request As Evidence

The first review item identifies open-design/web PR #2371, names “feat: orbit briefing card,” and shows “3 of 5 reviewers approved · waiting on you + cody.” Beneath it, the file path “src/components/OrbitBriefingCard.tsx” introduces a compact diff with removed and added lines. This pairing lets a reviewer connect the approval state to a concrete change. The tradeoff is vertical density: the code excerpt adds useful context, but it makes the first item substantially taller than the second request.

Engineering Triage Use Cases

The design supports several distinct tasks without pretending that they are the same kind of work. Review requests ask for a response or approval, CI checks signal a failed verification state, assigned issues represent owned backlog work, and activity records a completed change. Keeping these groups as separate panels makes the task boundary visible. The tradeoff is that related signals remain distributed across the page rather than being condensed into one universal score.

Workspace Reading Flow

The workspace uses a wide main column and a compact navigation rail rather than equal-sized dashboard tiles. The shipped CSS sets a 1280px maximum page width, and the visible layout gives the event panels most of the horizontal space. This proportion supports long repository names, pull-request titles, timestamps, and code lines without forcing each item into a separate card column. The cost is a long vertical scan, especially when the review request includes its embedded diff.

From Filter To Detail

The top search field reads Type / to search, but has no search handler. The sidebar filters do work on the supplied local groups: Participating shows review requests and assigned issues, Review requests shows the review group, and Mentions shows only the group carrying the source's mention marker. That marker is attached to assigned issues rather than the reply-needed review row. The filtering is local presentation behavior, not a connected GitHub search or inbox service.

State Changes Through Color

Color carries state across otherwise similar rows. Green marks open or healthy-looking repository states, yellow marks work waiting for a response, red marks the failed test, and purple marks the merged activity item. The issue labels use separate blue and pink pills for “backend” and “p1.” This makes scanning faster than reading every sentence, but color remains supplemental: each state is also written as text, which preserves meaning when color alone is insufficient.

Capability Boundary

The source implements local category filtering and constructs outbound GitHub links for rows and titles. Those links point to a fixed repository using the displayed sample identifiers; their existence does not verify the depicted pull requests, issues, or CI results. Search, authenticated inbox retrieval, persistent review state, and real test execution are not implemented. Names, counts, timestamps, approval states, and code excerpts remain illustrative content for the design scenario.