docs(merge-queue): add stacked PR support section to Chrome Extension page

[samgutentag]

Summary

Adds a "Stacked pull requests" section to the Chrome Extension docs explaining the new stack-aware panel: stack path display, speculative PR chip with link, and enqueue/cancel behavior that applies to the whole stack. Includes a hint linking to Trunk Sudo requirements.

Source

• trunk2 PR: https://github.com/trunk-io/trunk2/pull/3825

Test plan

• Preview in GitBook

---

Generated by Claude Code

[trunk-staging-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[claude]

Claude finished @samgutentag's task in 2m 0s —— View job

---

Claude PR Review

• Read the changed file and PR diff
• Check for typos, grammar, and formatting issues
• Compare with related docs for style consistency
• Post review feedback

---

Summary

The new Stacked pull requests section is well-scoped, scannable, and matches the page's existing voice and em-dash style. Cross-references (using-the-queue/stacked-pull-requests.md#merge-the-stack-as-one-unit and ../setup-and-administration/trunk-sudo-app.md) resolve correctly. Three issues worth addressing before merge:

1. Terminology inconsistency on line 51 (blocking) — the bullet calls the UI element a "Speculative PR chip," but the same sentence says it's "labeled Stacked PR #N," and the companion doc using-the-queue/stacked-pull-requests.md uses stacked PR throughout for this combined PR. Calling it both "speculative" and "stacked" in one sentence will confuse readers. See inline comment with a suggestion block.
2. Tense on line 51 — "the combined test PR Trunk created" → "Trunk creates" (describes general behavior, not a past event). Bundled into the same suggestion above.
3. Hint placement (lines 60–62) (non-blocking style) — the Trunk Sudo / /trunk stack prerequisite is currently at the bottom of the section. The page's existing convention (lines 8–10) puts prerequisite hints up top so readers don't miss them. Consider moving the {% hint %} directly under the heading.
4. Minor wording on line 55 (non-blocking) — "Any PR page in the stack triggers the same operation" reads awkwardly; suggested a tighter phrasing inline.

What looks good

• Heading capitalization (### Stacked pull requests) matches the page's sentence-case style.
• Em-dash usage matches the existing line 70 style (spaced em-dash).
• Bold UI labels (**Add to Merge Queue**, **Cancel**) match the conventions used in the Submit a pull request to the queue and Track testing progress sections.
• The deep link to #merge-the-stack-as-one-unit is correct.

Setting review_passed = false on the strength of issue 1 — the in-sentence terminology contradiction is a real reader-confusion problem that should be resolved before publishing.
• Branch

[claude]

Terminology inconsistency. This bullet describes the chip as a "Speculative PR chip" but in the same sentence says it is "labeled Stacked PR #N", and asks readers to click to "open the speculative PR." The companion page using-the-queue/stacked-pull-requests.md uses stacked PR consistently for this combined PR (the word "speculative" never describes this PR there — it only appears in the predictive-testing context).

Recommend renaming the chip and aligning the description with the rest of the docs:

Suggested change

	* **Speculative PR chip** — a link to the combined test PR Trunk created for the stack (labeled **Stacked PR #N**). Click it to open the speculative PR on GitHub and inspect its CI status.
	* **Stacked PR chip** — a link to the combined PR Trunk creates for the stack (labeled **Stacked PR #N**). Click it to open the stacked PR on GitHub and inspect its CI status.

Also note the small tense fix (Trunk created → Trunk creates) since this describes general behavior rather than a past event.

[claude]

Suggestion — surface the prerequisite earlier. Readers learn at the very end of the section that the whole flow requires Trunk Sudo and the /trunk stack workflow. The rest of this page (lines 8–10) follows the convention of placing prerequisite hints at the top so readers don't get partway through before discovering they can't use the feature.

Consider moving this {% hint style="info" %} block to immediately after the ### Stacked pull requests heading, before "What the panel shows."

[claude]

Minor — "Any PR page in the stack triggers the same operation" is slightly ambiguous (the page itself doesn't trigger anything; clicking the button does). Consider tightening:

Suggested change

	* **Add to Merge Queue** — enqueues the entire stack as one unit. Any PR page in the stack triggers the same operation.
	* **Add to Merge Queue** — enqueues the entire stack as one unit. Clicking it on any member PR page submits the same stack.

[claude]

Claude finished @samgutentag's task in 1m 8s —— View job

---

Claude PR Review

• Read the current state of the changed file
• Diff against origin/main to see latest changes
• Verify whether prior review feedback was addressed
• Check for new typos, grammar, formatting issues
• Post review feedback

---

Summary

The latest push (56e75db) is a merge of main into the branch — no content changes were made to merge-queue/chrome-extension.md since my earlier review. All three issues I flagged previously still apply, and the inline comments on lines 56, 60, and 67 remain unresolved.

Outstanding issues

1. Terminology inconsistency on line 56 (blocking) — the bullet still calls the UI element a "Speculative PR chip" while the same sentence labels it "Stacked PR #N" and tells the reader to click to "open the speculative PR." The companion page using-the-queue/stacked-pull-requests.md consistently uses stacked PR for this combined PR (verified — "speculative" appears there only in the unrelated predictive-testing context on line 142). Using both names in one sentence will confuse readers. See the inline suggestion block on line 56.
2. Tense on line 56 — "the combined test PR Trunk created" → "Trunk creates" (general behavior, not a past event). Bundled into the same suggestion.
3. Hint placement (lines 65–67) (non-blocking style) — the Trunk Sudo / /trunk stack prerequisite is still at the bottom of the section. The page convention (lines 8–10) puts prerequisite hints up top so readers don't get partway through before discovering they can't use the feature. Consider moving the {% hint %} directly under the ### Stacked pull requests heading.
4. Wording on line 60 (non-blocking) — "Any PR page in the stack triggers the same operation" is slightly ambiguous (the page doesn't trigger anything; the click does). A tightened version is suggested in the inline comment.

What looks good

• Heading capitalization (### Stacked pull requests) matches the page's sentence-case style.
• Em-dash usage matches the existing convention.
• Bold UI labels (**Add to Merge Queue**, **Cancel**) are consistent with neighboring sections.
• Cross-references to using-the-queue/stacked-pull-requests.md#merge-the-stack-as-one-unit and ../setup-and-administration/trunk-sudo-app.md resolve correctly.

Setting review_passed = false — issue 1 is the same in-sentence terminology contradiction flagged before, and it's still a real reader-confusion problem that should be resolved before publishing. Issues 3 and 4 are style suggestions and not blockers on their own.

Fix issue 1 →
• Branch

[samgutentag]

Verification status (2026-05-06): live

Verified: customers can use this. Ready to publish.

• Eng PR: trunk-io/trunk2#3825 (merged 2026-05-05)
• Flag: none
• Signals:
  • Merge commit on main (status: behind, merge intact)
  • No feature flag in eng PR body or diff (browser extension ships changes unflagged)

Branch state: up to date with main.

Suggested next action: merge.