` 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.

# This > Merge one PR via gh with a merge commit matching the repo's git history — readiness-gated, CI-watched, trunk synced after - Skill: `tony/this` (Agent Skill) - Install (CLI): `npx skillmds@latest add tony/this` - Raw SKILL.md: https://api.skillmd.com/api/skills/tony/this/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tony (https://skillmd.com/u/tony) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tony/this --- # 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 --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 --merge -t "" -b "" ``` 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: ` 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.