Update PR
The request authorizes the repository's declared PR gate, relevant commits, a
plain push to the current PR branch, and metadata reconciliation. It does not
authorize unrelated changes.
When the current PR belongs to a native GitHub stack, read
../git-workflow/references/github-stacks.md.
- Inspect repository state, recent commits, the remote default branch, and the
current PR, including its
mergeable_state: a dirty (unmergeable) PR gets no
pull_request workflow runs whatsoever, so missing CI is resolved by merging
the base per step 3, never by retriggers.
- Stop if on the base branch or no open PR exists; report the required next
workflow.
- When an ordinary branch is behind the remote base, merge it into the branch.
For a verified native stack, capture remote heads and use the guarded
gh stack sync or narrower official stack operation; never use raw rebase or
force-push commands.
- Run the repository's declared PR gate unless it already passed on the
unchanged current diff.
- Stage only relevant files and commit them with a concise Conventional Commit
subject. Never amend and never skip hooks.
- Push an ordinary branch normally, setting upstream when needed. Push a
verified stack only through the guarded official stack workflow.
- Reconcile the PR title and body with the current commits, scope, linked
issues, and observed verification. Keep the title a Conventional Commit
subject for the whole change; the squash merge makes it the commit subject on
the base branch, so widened scope may also change its type. Preserve the project template or existing
body structure and omit filler or repeated summaries.
- Report the commit, branch, PR URL, native stack position when applicable,
metadata changes, rewritten stack branches if any, and observed validation.
1---2name: update-pr3description: Commits relevant changes, merges the remote default when needed, pushes the current pull-request branch, and refreshes stale PR metadata. Use when the user runs /update-pr or asks to update a pull request.4license: Unlicense OR MIT5---67# Update PR89The request authorizes the repository's declared PR gate, relevant commits, a10plain push to the current PR branch, and metadata reconciliation. It does not11authorize unrelated changes.1213When the current PR belongs to a native GitHub stack, read14[../git-workflow/references/github-stacks.md](../git-workflow/references/github-stacks.md).15161. Inspect repository state, recent commits, the remote default branch, and the17 current PR, including its `mergeable_state`: a dirty (unmergeable) PR gets no18 pull_request workflow runs whatsoever, so missing CI is resolved by merging19 the base per step 3, never by retriggers.202. Stop if on the base branch or no open PR exists; report the required next21 workflow.223. When an ordinary branch is behind the remote base, merge it into the branch.23 For a verified native stack, capture remote heads and use the guarded24 `gh stack sync` or narrower official stack operation; never use raw rebase or25 force-push commands.264. Run the repository's declared PR gate unless it already passed on the27 unchanged current diff.285. Stage only relevant files and commit them with a concise Conventional Commit29 subject. Never amend and never skip hooks.306. Push an ordinary branch normally, setting upstream when needed. Push a31 verified stack only through the guarded official stack workflow.327. Reconcile the PR title and body with the current commits, scope, linked33 issues, and observed verification. Keep the title a Conventional Commit34 subject for the whole change; the squash merge makes it the commit subject on35 the base branch, so widened scope may also change its type. Preserve the project template or existing36 body structure and omit filler or repeated summaries.378. Report the commit, branch, PR URL, native stack position when applicable,38 metadata changes, rewritten stack branches if any, and observed validation.
frostney