create-pr ยท diff
git:20260722.8b54d94 to git:20260817.24aad63
1 added, 1 removed. Audit A to A.
---
name: create-pr
description: "Create a GitHub pull request with a drafted title and description. Use when the user asks to \"create a PR\", \"create a pull request\", \"open a PR\", or \"submit a PR\"."
---
# Create Pull Request
Draft a concise and descriptive title and a short paragraph 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 diagram opportunities (see Diagrams section below).
## Step 2: Run `/github-voice` Skill
Run the `/github-voice` skill to load writing style rules.
## Step 3: Draft Title and Description
Draft a title and description, 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 `AskUserQuestion` for confirmation only. Generate a random tag so the body file is unique across sessions:
```bash
head -c 4 /dev/urandom | xxd -p
```
Write the drafted body to `.turbo/pr/<tag>-body.md` (using the printed tag) with the Write tool, then create the PR with `gh pr create --body-file`:
```bash
gh pr create --title "<TITLE>" --body-file .turbo/pr/<tag>-body.md
```
Do not set `--assignee` unless the user explicitly asks to assign someone.
## Diagrams
GitHub renders Mermaid natively in PR descriptions via ` ```mermaid ` code blocks. Include diagrams only when they add clarity a text description can't โ skip for trivial changes or obvious flows.
### Sequence Diagram
Include when the changes introduce or modify a clear runtime flow: API endpoints, event handlers, pipelines, multi-service interactions, webhook flows.
````markdown
```mermaid
sequenceDiagram
Client->>API: POST /payments
API->>PaymentService: processPayment()
PaymentService->>StripeClient: charge()
StripeClient-->>PaymentService: confirmation
PaymentService->>DB: save()
```
````
### State Diagram
Include when the changes add or modify entity states, status enums, workflow transitions, or lifecycle hooks.
````markdown
```mermaid
stateDiagram-v2
[*] --> Draft
Draft --> Pending: submit()
Pending --> Approved: approve()
Pending --> Rejected: reject()
Approved --> [*]
```
````
### Rules
- Only include when the diagram genuinely adds clarity
- Keep diagrams focused โ max ~10 nodes/transitions
- Use descriptive labels on arrows (method names, HTTP verbs)
- Place diagrams after the summary paragraph under a `## Flow` or `## State Machine` heading
- One diagram per type max โ don't include both unless the PR truly has both patterns
## Rules
- - Don't reference `.turbo/` content (filenames, requirement IDs, shell references, headings) in the title or body. `.turbo/` is gitignored, so these references would be opaque to anyone reading without local copies.
+ - Don't reference `.turbo/` content (filenames, acceptance criteria, step numbers, headings) in the title or body. `.turbo/` is gitignored, so these references would be opaque to anyone reading without local copies.