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