Before submitting
Area
apps/web
Problem or use case
GitHub now supports stacked pull requests, and I use stacks frequently to split larger changes into reviewable steps. T3 Code's new PR panel is already useful for looking after an individual PR, but it does not expose the surrounding stack.
That means I still have to switch to GitHub to answer basic stack-level questions: which PR comes next, which PRs are blocked by an earlier one, whether every layer has passing checks and approvals, and where review attention is needed.
Proposed solution
Add a stack view or stack section to the PR panel when the selected PR belongs to a GitHub PR stack. Show the PRs in dependency order and, for each layer, the key state already useful in the individual PR view:
- PR number and title
- base/head relationship or position in the stack
- draft/open/merged state
- checks and review status
- merge readiness or blockers
- a way to open that PR in the existing panel
The currently selected PR should be clearly highlighted. The view could be a dedicated "Stack" tab or a collapsible section beside the existing PR details.
Why this matters
Stacked PRs trade one large review for several small ones, but they add coordination overhead. A stack-aware panel would make T3 Code a much better place to monitor and review the full unit of work without repeatedly jumping between individual GitHub pages. It would help both authors maintaining a stack and reviewers working through it in order.
Smallest useful scope
A read-only list of all PRs in the selected PR's GitHub-native stack, ordered from base to tip, with each PR's open/merged, checks, and review state plus navigation into the existing PR view.
Creating, restacking, updating bases, and merging the full stack can remain out of scope for the first version.
Alternatives considered
Today I use GitHub's stack UI in a separate browser tab and move between individual PRs in T3 Code. This works, but splits the review workflow and makes it easy to miss a failing or blocked layer.
A generic related-PR list would help somewhat, but using GitHub's native stack relationship should be more reliable and makes the ordering explicit.
Risks or tradeoffs
- GitHub's stacked PR APIs and feature availability may evolve while the feature is new.
- Large stacks need a compact or scrollable presentation.
- Forks, deleted branches, partial stacks, and mixed draft/merged states need graceful handling.
- The UI should distinguish dependency order from merge readiness so users do not interpret position alone as safe-to-merge.
Examples or references
GitHub's native stacked pull request view is the relevant prior art. The request is to surface its stack context inside T3 Code's existing PR panel.
Contribution
Before submitting
Area
apps/web
Problem or use case
GitHub now supports stacked pull requests, and I use stacks frequently to split larger changes into reviewable steps. T3 Code's new PR panel is already useful for looking after an individual PR, but it does not expose the surrounding stack.
That means I still have to switch to GitHub to answer basic stack-level questions: which PR comes next, which PRs are blocked by an earlier one, whether every layer has passing checks and approvals, and where review attention is needed.
Proposed solution
Add a stack view or stack section to the PR panel when the selected PR belongs to a GitHub PR stack. Show the PRs in dependency order and, for each layer, the key state already useful in the individual PR view:
The currently selected PR should be clearly highlighted. The view could be a dedicated "Stack" tab or a collapsible section beside the existing PR details.
Why this matters
Stacked PRs trade one large review for several small ones, but they add coordination overhead. A stack-aware panel would make T3 Code a much better place to monitor and review the full unit of work without repeatedly jumping between individual GitHub pages. It would help both authors maintaining a stack and reviewers working through it in order.
Smallest useful scope
A read-only list of all PRs in the selected PR's GitHub-native stack, ordered from base to tip, with each PR's open/merged, checks, and review state plus navigation into the existing PR view.
Creating, restacking, updating bases, and merging the full stack can remain out of scope for the first version.
Alternatives considered
Today I use GitHub's stack UI in a separate browser tab and move between individual PRs in T3 Code. This works, but splits the review workflow and makes it easy to miss a failing or blocked layer.
A generic related-PR list would help somewhat, but using GitHub's native stack relationship should be more reliable and makes the ordering explicit.
Risks or tradeoffs
Examples or references
GitHub's native stacked pull request view is the relevant prior art. The request is to surface its stack context inside T3 Code's existing PR panel.
Contribution