writing-pr

Writing a PR title and body

Reviewers skim. Put the shape of the change on the first screen, then let diagrams and code carry the detail.

Title

• Conventional Commits, matching git log:

fix(playwright): provision the browser in a runner-side prepare hook. PRs squash-merge with the number appended, so the title is the commit.

• Mark spec or API breaks with ! (feat(config)!: ...), same as the commit.
• Name the outcome, not the activity. "install builds with the appPath

option", not "agent-device changes".

Body

Do not write essays. A few bullets on what changed and why, then evidence.

• Bullet points for the prose you do write. One fact per bullet.
• A mermaid diagram for anything with flow or state: runner phases, engine

hooks, replay paths, before/after architecture.

• Code samples: the new API, sample usage in a test file, or the key internal

snippet. Fenced blocks with a language tag.

• Code refs (packages/e2e/src/run/execute.ts:42, GitHub permalinks) instead

of paraphrasing code.

• Visual changes, direct or indirect (CLI output, reporter output, docs

pages): a before/after table with uploaded images or videos.

• Benchmarks: a before/after table. Baseline is the target branch, candidate

is the PR.

• Spec changes: name the chapter, schema, and suiteVersion bump in one

bullet so the reviewer can check them together.

• A ## Verified section, required on every PR:
• First line: Ran it locally: yes, or Ran it locally: no - <why>

(docs typo, CI-only, a device you do not have).

• With yes: the verify surface, the command you

ran, what you saw, and the CLI output, screenshots, or video showing it work.

• A fix PR with yes also shows the bug and the fix side by side in a

| main | this branch | table.

• Upload media with gh 2.99+ --attach: reference images in the body as

markdown (![after](./after.png)) and pass each file as --attach; gh uploads them and rewrites those paths. Do not write video paths in the body: attached videos are appended at the end and render as players.

Leave out

• "I ran lint/tests" lists. CI reports that; ## Verified is for what CI

cannot see.

• Intermediate history. Squashed 6k lines down to 1k, refactored twice,

renamed midway: none of it lands. Only the final aggregate squash-merge commit exists, so only that gets commentary.

• Line-by-line restating of the diff.
• Checklists nobody asked for, sign-offs, filler.

Templates

Before/after for visuals:

| Before | After |
| --- | --- |
| ![before](url) | ![after](url) |

Verified, for a fix (local image paths become uploaded assets with --attach):

## Verified

Ran it locally: yes
- testbed, `e2e run tests/scroll.e2e.ts --video`: the new test fails on main
  and passes here

| main | this branch |
| --- | --- |
| ![bug](./main.png) | ![fixed](./branch.png) |

gh pr edit <pr> --body-file body.md --attach ./main.png --attach ./branch.png --attach ./video.webm

Benchmarks:

| Scenario | main | this PR | delta |
| --- | --- | --- | --- |
| testbed default suite | 41s | 23s | -44% |

Flow:

flowchart LR A[collect] --> B[schedule] B --> C{cache hit?} C -- yes --> D[replay] C -- no --> E[act]

Big changes

For truly impressive, difficult, high-risk, or wide-scoped changes, write the body like a technical blog post: context, the problem, the approach, code samples, diagrams, before/after, images. Storytelling is fine here. The rules above still hold: run output only as ## Verified evidence, no intermediate history.

Voice

Run the unslop pass on the final text before posting. PR-specific tells to catch:

• "This PR introduces...", "comprehensive", "robust", "seamless", "ensures",

"leverages", "enhances".

• Bold label lists that restate the line (**Performance:** Performance...).
• Em dashes. Use a comma, a colon, or a new sentence.
• Bullets padded to three because three felt right.
• A summary that could be pasted unchanged into another repo's PR.