💡 Stacked PR Awareness for Review and Dev-Lead Pipelines

[github-actions[bot]]

Summary

Adapt the pr-review pipeline and dev-lead agent to understand GitHub's new Stacked PRs (announced April 2026, preview). When reviewing a stacked PR, include the parent PR's context in the review prompt so the reviewer understands the incremental change. When dev-lead creates related sub-issue PRs from an initiative, create them as a stack rather than independent PRs.

Market Signal

GitHub unveiled Stacked PRs on April 14, 2026, specifically citing the rise of AI-assisted coding tools as the motivation — AI agents generate higher PR volumes that need better review organization. The feature is paired with the gh-stack CLI extension. This is likely to reach GA within 2026 and become a standard workflow pattern for AI-heavy teams. GitHub's blog post states: "The release of Stacked PRs is a response to the rise of AI-assisted coding tools, which have greatly increased the volume and scale of code submissions."

User Signal

• The existing oversized-PR handling (AGENTS.md: >300 changed files triggers truncated review) is a symptom of the problem Stacked PRs solve
• Initiative-driven development (Cross-repo impact-aware review annotations: proactive downstream-breakage detection in the pr-review pipeline #748, 💡 Adversarial Plan-Critic + Structural Gates for the Initiative-Planner (Bob) #593) regularly produces chains of dependent PRs from sub-issues that would benefit from explicit stack relationships
• The pr-review agent currently reviews each PR in isolation, missing cross-PR context that would improve review quality

Technical Opportunity

The pr-review pipeline (scripts/review-one-pr.sh, scripts/engine.sh) already receives PR metadata via the GitHub API. Detecting stack membership requires querying the gh-stack API for the PR's stack position and parent. The review prompt can be enriched with a "Stack Context" section summarizing parent PR changes. The dev-lead's PR creation flow (scripts/dev-lead-fix-issue.sh) can use the gh-stack CLI to create stacked PRs from ordered sub-issues.

Assessment

Dimension	Score	Rationale
Feasibility	med	Depends on preview API stability; graceful degradation needed
Impact	med	Improves review quality for initiative-driven PR chains; positions for GA
Urgency	med	Feature is in preview; early awareness is valuable but not blocking

Adversarial Review

Strongest objection: Stacked PRs are still in private preview — building on a preview feature risks wasted effort if the API changes or the feature is delayed/altered before GA.

Rebuttal: The proposal is intentionally low-investment at this stage: Phase 1 is detection-only (add stack metadata to review context if available, no-op if not). The gh-stack API is stable enough for read operations. The review context enrichment degrades gracefully — if a PR is not part of a stack, nothing changes. Building awareness now positions the pipeline to leverage stacks immediately when GA lands.

Suggested Next Step

Join the Stacked PRs waitlist, evaluate the gh-stack CLI API surface, and prototype a stack-detection script that enriches PR review context with parent PR summaries.

[github-actions[bot]]

Weekly Update

What Changed

Stacked pull requests went GA on Oct 6, 2026 (GitHub changelog). The original idea's main objection was "preview-only, the API may change", and that no longer holds. Details that matter for this pipeline:

• A stack enters the merge queue as one merge group. This links directly to 💡 Merge Queue Readiness: Systematic Prerequisites to Break the O(n²) Re-Review Deadlock #1939 (merge queue readiness). Stacks and the queue now have to be designed together, not separately.
• One merge commit per PR when the merge-commit method is used. History stays per-PR, so release-notes.sh and the claim-landing and stale-base checks keep per-PR granularity.
• Auto-merge for stacks is rolling out over the next few weeks. scripts/lib/auto-merge.sh will need to tell "my PR is approved" apart from "my stack is mergeable".
• The async merge API (GA Oct 1) is the only merge API that supports stacks (changelog). Any stack support therefore depends on moving the merge call to that API.
• Approvals survive rebases inside a stack ("preserved approvals"). That speaks to the re-review cascade this fleet suffers on rebases (💡 Merge Queue Readiness: Systematic Prerequisites to Break the O(n²) Re-Review Deadlock #1939's O(n²) problem). It applies only to stacked PRs.
• Reported effect: 9% more merged code for repos using stacks, and a 5% better time-to-merge for the top 1% of repos.

Third-party merge queues followed earlier: Trunk (Jul 31) and Mergify (Aug 12) both merge GitHub stacks.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	med	high	↑ GA API surface plus the async merge API; no longer building on a preview
Impact	med	med	→ Still mostly helps initiative-driven PR chains. Preserved approvals could raise this if they apply to dev-lead's rebases
Urgency	med	med	→ Nothing breaks if we wait. Stack auto-merge is still rolling out, so the useful window is when it lands

Recommendation

Advance, and couple it to #1939. A cheap first slice that holds up under scrutiny:

1. Read-only detection. Have review-one-pr.sh record stack membership and parent PR in the review context (no behaviour change).
2. Merge path. Track the move of auto-merge.sh to the async merge API as a prerequisite shared with 💡 Merge Queue Readiness: Systematic Prerequisites to Break the O(n²) Re-Review Deadlock #1939, because stacks cannot merge any other way.
3. Defer dev-lead creating stacks from initiative sub-issues until the auto-merge-for-stacks rollout finishes. Then pilot it on one initiative and measure re-review counts against non-stacked chains.