create-pr

name	create-pr
description	Write and publish a PR for the current branch as a draft, in English. Use when the user says "create PR", "open PR", "submit PR", or wants to publish their branch for review.

Write and publish a PR for the current branch as a draft, in English.

Before creating the PR

• Run bundle exec i18n-tasks normalize if any locale file changed.
• Run bin/rails test on the affected test files.
• Run bundle exec rubocop <changed_files> and npm run eslint / npm run stylelint if Ruby or JS/CSS changed.
• Re-read @AGENTS.md "Best Practices" sections to make sure the relevant conventions are honored (site scoping, modular layout, service patterns, strong params, tests).

PR content

• Use the template at .github/PULL_REQUEST_TEMPLATE.md — fill the existing sections, don't invent new ones.
• Title: capitalized, in English, under ~70 characters. Use the body for details.
• "What does this PR do?": one short paragraph framed around user-visible outcome (or developer-visible outcome for refactors).
• "How should this be manually tested?": concrete steps. If the change has UI, include the path to visit. If the branch has been deployed to staging (check with git branch --contains HEAD staging), include the staging URL — otherwise note that a staging deploy is needed first.
• Tick the "Does this PR change any configuration file?" boxes if you added/changed env vars, config/application.yml, or config/secrets.yml — Ansible may need updates.
• Tick the "Does this PR require updating the documentation?" boxes if site config, templates, or modules changed.

Publish

gh pr create --draft --base master --title "<title>" --body-file /tmp/pr-body.md

Use --body-file (write the body to /tmp/pr-body.md first) rather than --body "..." — heredocs and backticks get mangled when passed inline.

After creating the PR, surface the URL to the user.