--- name: pr-update description: >- Open a PR/MR if missing, or refresh an existing one's title and description so they match the current diff. Preserves any media already in the body. Use when the user says /pr-update, open a PR, update the PR, refresh the PR title/description, or wants the PR opener/manager flow. --- # 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 ...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: ```markdown ## Summary <1-3 bullets of what changed and why> ## Test plan - [ ] ``` - 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 ..HEAD` before force-push. Two traps in that recipe: - Soft-reset to the branch's **real base SHA** (`git merge-base HEAD origin/`), never to `origin/` itself — it moves mid-task and will stage other people's commits as yours. - `git reset -- ` leaves that path **unstaged**, so the next `git commit` silently captures its pre-edit version. Verify the content landed (`git show : | grep `) 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. ## Preserve media (hard rule) When a PR/MR already has a body, **never delete media**. Treat as media (keep verbatim, same URLs/markup/order when possible): - Markdown images / links to images or video (`![](...)`, `[...](...)` to media) - HTML ``, `