# rd-pr

> Open one pull request for the tree, with every sibling issue id rewritten so merging cannot close work nobody reviewed.

`rd-pr` commits, pushes and opens one pull request for the whole tree, with a
body that describes the work without handing the forge a list of issues to
auto-close. After the merge it re-reads each issue it mentioned and repairs any
status that flipped.

> Open the pull request for a tree in Radial, the keyboard-first issue tracker
> with a branch named from the issue, the base synced, the gate green, and
> every issue id in the PR text rewritten except the branch's own.

## When to use it

Every child is in review and the gate is green. Not mid-build, and not when a
pull request already exists for this branch: push to that one.

## What it asks you

Nothing it can determine. It finds the integration branch (`dev` if the remote
has one, else the default branch), reads the last twenty commit subjects to
match your message convention, and checks whether a pull request is already
open before creating one. It stops and tells you, rather than asking, when the
gate is red or the branch is behind base.

## What it writes

Commits on the branch the parent id names, the pushed branch, and one pull
request. In Radial, only repairs: after a merge it restores any status a
closing keyword flipped, and names which ones it repaired.

## The scrub, and why it exists

A merged pull request whose body says `closes RAD-12` closes RAD-12. A body
that lists a whole tree therefore closes the whole tree on merge, including
children nobody reviewed. So in the title and body:

- The branch's own issue id appears bare, once.
- Every other `KEY-n` is rewritten so no automation can match it, using a
  non-breaking hyphen (`RAD‑34`) or the words (`issue 34`). The body says
  which convention was used, so a reader is not confused by the lookalike.
- No `closes`, `fixes` or `resolves` in front of any id.

Before creating the pull request it greps its own body for `KEY-` and confirms
every hit is either the branch's id or already rewritten. After the merge, the
read-back is what catches a scrub it got wrong.

## Extension points

<hook-table skill="rd-pr">
</hook-table>

## A worked wrapper

```markdown
---
name: release-pr
description: Our pull-request rules on top of rd-pr. The checklist, the approver, the announcement.
extends: rd-pr
---

Read rd-pr first, then apply the sections below at their hooks.

## extra-checks

- Every user-visible change needs a `.changeset/` entry before committing.

## extra-sections

- The body carries a `## Rollout` section: flag name, default, and who flips it.
- The body carries a `## Screenshots` section for any `[ui]` child, or the line
  "no visible change".

## merge-bar

- A pull request touching `src/billing/` needs an approval from @finance-eng
  before it leaves draft.

## after-pr

- Post the pull request URL to #releases with the parent issue link.
```

## What it never does

It never leaves a bare sibling issue id in the pull request text. It never
merges and never closes an issue. It never opens a second pull request for a
tree that already has one, and it never opens one from a branch that is behind
its base or on a red gate.