This

---
name: this
description: Merge one PR via gh with a merge commit matching the repo's git history — readiness-gated, CI-watched, trunk synced after
allowed-tools: ["Bash", "Read", "Grep", "Edit", "AskUserQuestion"]
argument-hint: "[PR number or URL] [--squash | --rebase | any other gh pr merge flag]"
user-invocable: true
disable-model-invocation: true
---


# Merge This PR

Merge a single pull request — the one this conversation is about, or
the one the current branch belongs to — via `gh pr merge`, with a
merge commit whose message matches the repository's own
`git log --merges` history. Nothing merges until the readiness gate
passes.

Read `../../references/merge-readiness.md` first; it
defines the readiness gate, the rebase procedure, the merge-message
derivation, flag passthrough, the `--admin` policy, and the rule that
merging is not releasing.

User arguments: $ARGUMENTS

## Context

Current branch:
`!git branch --show-current`

PR for the current branch:
`!gh pr view --json number,title,url,state,isDraft,baseRefName,mergeable,mergeStateStatus,reviewDecision 2>/dev/null || echo "(no PR for current branch)"`

Checks:
`!gh pr checks 2>/dev/null || echo "(no PR or no checks)"`

## Procedure

### 1. Identify the PR

Precedence: an explicit argument (number or URL) > the PR this
conversation has been working on > the current branch's PR. If the
candidates disagree — the argument names one PR while the
conversation is about another — ask via `AskUserQuestion` before
proceeding.

### 2. Run the readiness gate

Apply the readiness gate from the reference. Pending checks are
waited on with `gh pr checks <n> --watch`; failing checks, a draft
state, or `CHANGES_REQUESTED` halt with a report. If the PR is
`BEHIND` or `DIRTY`, confirm with the user, then follow the rebase
procedure: rebase, resolve conflicts, verify content did not drift,
`git push --force-with-lease`, and watch CI again.

### 3. Compose the merge commit message

Follow the merge-message section of the reference: study
`git log --merges` on trunk, match the observed format, keep the body
proportional to the change, and stay provincial — no release or
version claims unless the PR itself is release work. Skip this step
when the user's flags make the message theirs to control (their own
`-t`/`-b`, or `--rebase`, which produces no merge commit).

### 4. Merge

Default to a merge commit; pass the user's `gh pr merge` flags
through verbatim:

```console
gh pr merge <n> --merge -t "<subject>" -b "<body>"
```

Use `--admin` only within the reference's policy — CI green, blocked
purely by branch protection, nothing violating AGENTS.md — and ask
first if the user did not pass it.

### 5. Sync trunk and stand by

Checkout trunk, pull, and confirm the PR reports merged. Then stop:
no tagging, no releasing, no follow-on work.

## Rules

- The merge goes through `gh pr merge`, never a local `git merge`
  pushed to trunk.
- Never merge over failing or pending CI, with or without `--admin`.
- Force-pushes use `--force-with-lease` and only ever target the PR
  branch.
- When in doubt at any step, ask — an unnecessary question costs a
  moment; a wrong merge costs an afternoon.

## Output

Open with a one-line hero (`✓ Merged #N: <title>` or
`⚠ Blocked: <reason>`), then exactly these sections:

1. `## Merge readiness` — the gate results, including anything that
   required a rebase or a wait on CI.
2. `## Merge` — strategy used, flags passed through, and the merge
   commit subject (or why no merge happened).
3. `## Trunk` — the post-merge trunk state after checkout and pull.

End with an `AskUserQuestion` panel offering next steps (for example:
cut a release from the merged trunk, merge another PR, delete the
local branch, stop here) — skip the panel only in plan mode.

Offer the release when the merged trunk is a releasable state and the
repo carries the version files a release touches; name the skill that
cuts it rather than the git commands. Tagging and pushing stay the
user's explicit act either way.