Skill: Open a PR

A PR body is read in thirty seconds, before the diff. It answers a few questions and stops. Everything else lives in the commit messages, the spec, and the report CI posts.

The shape

.github/pull_request_template.md. Fill every heading; add none. Under ~250 words total.

## What is this about?
One or two sentences, plain words: the surface and the change.

## What problem does it solve?
The pain a person felt or the risk we carried. Not the mechanism.

## What was the situation before?
What the person saw or could not do. Concrete enough to recognise in the
"before" screenshot.

## How is this implemented?
Two to five bullets for the reviewer: the main pieces that changed and how
they connect, so the diff reads in order. File paths, tool names, routes and
flags go here, not in the sections above.

## What else changed?
Anything in the diff that is not part of the main task: drive-by fixes,
refactors, renames, dependency bumps, test or tooling tweaks. One bullet
each, so the reviewer is not surprised by them. `none` if nothing.

## Release note
One sentence for people who use OpenWork, or `none`.

## Evidence
The spec that proves it, and in one line what its before → after shows.

The release note feeds the changelog agent directly (scripts/release/collect-release-prs.mjs). Write what a user can now do or no longer hits, in words they see in the product: "Connecting an account in chat no longer gets stuck on 'Checking connection request…'." Write none for CI, tests, review tooling, or refactors nobody will notice; the PR is then left out of the changelog. A change that removes or alters something users rely on always needs a note.

Title: conventional commit, imperative, under 70 characters.

Evidence

CI runs every spec the PR changes on the PR head and posts one sticky <!-- test-evidence --> comment linking the report. You never run the publisher or attach screenshots by hand. The body names the spec and says what the reader will see; it does not copy verdicts, SHAs, screenshots or links, which go stale.

## Evidence
`evals/specs/browser-tabs-owned-by-thread.e2e.test.ts` — before: the toolbar
shows Suspend; after: it does not, and a page still opens and can be used.

• The before: here and "What was the situation before?" are the same moment. If they disagree, fix one.
• No spec changed? Say why in one line, e.g. No E2E; typecheck and build only. If no evidence comment appears, that is why; do not run a spec locally and paste its output.
• Red evidence needs no sentence in the body: CI's comment says Failed on that SHA and flips on its own when the head goes green. Fix the spec or the code; do not narrate the verdict.
• Evidence binds to a commit. After a rebase or cherry-pick, wait for CI to rerun on the new head; do not cite the old comment.
• UI changes: one trailing line Design: P3, S4, C6 (DESIGN.md rule ids).

Leave out

Root-cause narrative (commit message). Suite counts and CI matrices (the Required verification check). Image digests, worktree setup, credential notes (the spec's world). Other PRs' failures (an issue). Risk, Rollback, Out-of-scope boilerplate. Caveats about your caveats.

Do it

gh pr create --base dev --title "<type>(<scope>): <change>" --body-file /tmp/pr-body.md
gh pr edit <n> --body-file /tmp/pr-body.md

Write the file first and read it as the reviewer would. If a section makes you scroll, cut it.