Create Pull Request

Create Pull Request

Draft a concise and descriptive title and a body for a PR. Explain the purpose of the changes, the problem they solve, and the general approach taken. When the changes involve clear runtime flows or state transitions, include Mermaid diagrams.

Step 1: Analyze Changes

If git is in a feature branch, examine all commit messages and the full diff to understand the overall changes. Analyze the diff for framing and diagram opportunities.

Source every claim about prior behavior from the base branch itself, by reading its code with git show origin/<base>:<path>. A long session leaves the working tree carrying intermediate states that were never the state this PR is measured against, and describing one of those as the prior behavior misleads the reviewer.

Before writing that two pull requests must land together, check whether the consumer uses what changed: git grep <symbol> in its checkout, or the other repository's working copy when the dependency crosses repositories. When it does, name the actual cause. When it does not, drop the landing-order claim and keep any reference to the related pull request as plain context. State the claim as unverified when the consumer is not reachable.

Step 2: Run $github-voice Skill

Run the $github-voice skill to load writing style rules.

Step 3: Draft Title and Description

Pick a framing, then draft a title and description in it, embedding any diagrams in the body. Output the drafted title and description as chat text so the user can review it.

Step 4: Confirm and Create

Use request_user_input for confirmation only. Generate a random tag so the body file is unique across sessions:

head -c 4 /dev/urandom | xxd -p

Write the drafted body to .turbo/pr/<tag>-body.md (using the printed tag) with apply_patch, then create the PR with gh pr create --body-file:

gh pr create --title "<TITLE>" --body-file .turbo/pr/<tag>-body.md

Do not set --assignee unless the user explicitly asks to assign someone.

Framing

Every body says what the change does and why. How it is organized past that follows from what the change is: pick the framing that carries the most user-visible meaning, and combine two when the change genuinely has both shapes.