pr-update

PR Update (open or refresh)

One skill for create and update. Make the title + body match the branch as it is now. Do not strip media from an existing description.

Steps

1. git status / git diff / git log / git diff <default>...HEAD (and remote tracking) so you know the full change set — not just the latest commit.
2. Detect an existing PR/MR for this branch (gh pr view / glab mr view).
   • None → create (push upstream with -u if needed).
   • Exists → edit title + body in place. Do not open a duplicate.
3. Draft a title and body from all commits/files in the PR, not one commit.
4. If updating: fetch the current body first. Preserve every media item exactly (see below). Then rewrite text so Summary / Test plan (or the repo's usual sections) stay accurate.
5. Apply with gh pr create / gh pr edit (or glab equivalents).
6. End with the PR/MR as a markdown link — the number and the full forge URL ([#123](https://github.com/org/repo/pull/123), GitLab ! equivalent). Never a bare #123. This is the one place the rule is written down; the other skills just follow it.

Title + body

• Title: concise, why-focused; match repo PR style when obvious.
• Body: use the repo's template when one exists; otherwise:

## Summary
<1-3 bullets of what changed and why>

## Test plan
- [ ] <concrete checks>

• Run the prose through no-tropes before publishing.
• Do not invent reviewers, labels, or milestone unless asked.

Commits

Shape the branch's commits as part of opening/refreshing the PR.

• Check effective user.name and user.email before committing. GitHub login does not set commit attribution. If email is unset or Git infers a local-host address, stop before publishing and confirm an account-associated email. Never publish after ignoring Git's inferred-identity warning.

• One concern per commit. Default to a topical split (2–5 is typical) even if not asked; don't dump everything into one blob unless the user wants it.

• Match the repo's recent commit style (git log --oneline -15); subject = why. No "WIP" / "fix stuff".

• Rebuild with soft reset + path-staged commits (no git rebase -i — needs a TTY). Show the final git log --oneline <default>..HEAD before force-push. Two traps in that recipe:

  • Soft-reset to the branch's real base SHA (git merge-base HEAD origin/<default>), never to origin/<default> itself — it moves mid-task and will stage other people's commits as yours.
  • git reset <base> -- <path> leaves that path unstaged, so the next git commit silently captures its pre-edit version. Verify the content landed (git show <sha>:<path> | grep <new symbol>) before force-push.

• Keep authorship when reshaping others' work (Co-authored-by / cherry-pick), especially during pr-triage salvage.

• Don't mix pure formatting with logic, commit secrets/.env, or rewrite commits already on the default branch without asking.