| name | submit-pr |
| description | Open a PR for the current change — branch, optional changelog fragment, and gh pr create. Use when asked to submit, open, or ship a PR. |
Submit a PR
Ship the working-tree change as a PR off master.
1. Branch & commit
- Never commit to
master — branch first: git checkout -b !git config github.user/<short-name>.
- Stage specific paths only (
git add <path> …), never git add ..
- Commit body in complete sentences; do not list yourself as co-author.
2. Changelog — only when the change is user-visible
Add a fragment iff a user would observe the change: behavior, stack output,
API, CLI, or error text. Skip it for refactors, tests, CI, comments, or any
internal-only change.
Write .changes/unreleased/<component>-<kind>-<number>.yaml:
kind: bug-fixes
body: Add `base64gunzip`, `urldecode` and `cidrcontains`
time: $(date -u +"%Y-%m-%dT%H:%M:%SZ")
custom:
Component: runtime
PR: "<number>"
body is terse — a short phrase naming the user-facing change (e.g.
Add `base64gunzip`, `urldecode` and `cidrcontains` ), not an
explanatory sentence. The why and how belong in the PR description, not here.- Quote every function or feature name in
backticks.
- It does not end in punctuation.
- One fragment per user-visible change.
3. Pick the number
- If the change closes an issue, use that issue number.
- Otherwise it is the next PR number: guess it as one past the highest of
gh pr list --state all --limit 1 and gh issue list --state all --limit 1,
then check it after gh pr create — if the real number differs, rename the
fragment file and update its PR: field to match with a force push.
4. Create
gh pr create — title and body describe the change; link any issue with its full
https://github.com/… URL.
