pr-description

name	pr-description
description	Writes pull request descriptions following the project's PR template. Use when creating a PR, writing a PR, or summarizing changes for a pull request.
allowed-tools	Bash, Read, Grep, Glob
license	MIT

Write a pull request description for the current branch.

Branch context (pre-fetched)

Base branch: !git rev-parse --verify develop 2>/dev/null && echo "develop" || git rev-parse --verify main 2>/dev/null && echo "main" || echo "master"

Commits on this branch: !BASE=$(git rev-parse --verify develop 2>/dev/null && echo develop || git rev-parse --verify main 2>/dev/null && echo main || echo master); git log "$BASE"...HEAD --oneline 2>/dev/null || echo "(no commits diverged from $BASE)"

Changed files: !BASE=$(git rev-parse --verify develop 2>/dev/null && echo develop || git rev-parse --verify main 2>/dev/null && echo main || echo master); git diff "$BASE"...HEAD --stat 2>/dev/null || echo "(no diff found)"

Full diff: !BASE=$(git rev-parse --verify develop 2>/dev/null && echo develop || git rev-parse --verify main 2>/dev/null && echo main || echo master); git diff "$BASE"...HEAD 2>/dev/null || echo "(no diff found)"

Steps

1. Read the PR template

Read .github/PULL_REQUEST_TEMPLATE.md and follow its structure exactly. The template has these sections:

• What — brief description, link to issue
• Why — motivation, problem solved
• How — implementation approach, non-obvious design decisions
• Testing — checkboxes for pnpm run check, pnpm run lint, manual testing
• Checklist — ADR-035 scope, performance budgets, no client:load without ADR, design tokens, TypeScript strict, accessibility
• Screenshots — before/after for UI changes

2. Write the description

Read through ALL commits above, not just the latest. The PR description must cover the entire branch.

Fill out every section of the template. For the checklist, check each box that applies based on the actual changes.

Call out non-obvious design decisions in the How section. If there were alternatives you considered, mention why this approach was chosen.

3. ADR check

Check whether changes touch areas covered by existing ADRs in docs/adr/. If changes introduce a new architectural decision not covered by an existing ADR, add a note:

Note: This PR introduces [decision]. Consider documenting this in a new ADR.

4. Output

Print the complete PR description in markdown, ready to paste into GitHub. Do not wrap it in a code fence — output raw markdown.