Skip to content
Automation
Skill

/merge

Merge the reviewed pull request for the current branch, then hand straight off to cleanup. A sentence of editorial direction alongside the green light is read as a rider. Use when a human green-lights an open PR.

From plugin
csw
35 skills
Install
$ npx -y skills add mikestankavich/claude-ship-workflow --skill merge --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/merge

Context preview

The summary Claude sees to decide when to auto-load this skill.

Merge the reviewed pull request for the current branch, then hand straight off to cleanup. A sentence of editorial direction alongside the green light is read as a rider. Use when a human green-lights an open PR.

SKILL.md

merge.SKILL.md
name: merge
description: Merge the reviewed pull request for the current branch, then hand straight off to cleanup. A sentence of editorial direction alongside the green light is read as a rider. Use when a human green-lights an open PR.
when_to_use: "go for merge", "diffs look good", "merge it", "ship it", "land it", "approved, merge", "go for merge — reviewed the ADR, all good"
argument-hint: "[pr-or-ticket-ref] [editorial rider]"

Merge a reviewed pull request

**Announce at start:** "Using csw:merge to land PR #<n>." Where the invocation carried an editorial rider — Step 1 — echo it verbatim on that same line: `— rider: "<what they wrote>"`.

Step 1: Resolve the PR

The invocation optionally carries one reference. **Bare `/csw:merge` is unchanged** — it means the pull request for the current branch:

gh pr view --json number,title,url,isDraft,mergeable,mergeStateStatus,baseRefName,headRefName

**`/csw:merge <ref>` names the pull request, and the reference is not decorative.** Resolve it. Never fall through to the current branch's PR because the reference was harder to read than `gh pr view` with no argument.

  • **A prefixed reference** — `ENG-92` — is a **ticket**. Resolve it to the PR that closes it,

below.

  • **A bare number, or `#92`, on `tracker: github`** is either an issue or a pull request.

GitHub numbers both out of one sequence per repository, so the number is never ambiguous about which object it names — but you have to ask, and you have to ask about the **PR**:

  gh pr view 92 --json number,title,url,isDraft,mergeable,mergeStateStatus,baseRefName,headRefName

It resolves, and 92 is the pull request. It fails with `Could not resolve to a PullRequest with the number of 92`, and 92 is an issue — resolve it to its PR below.

**Do not run `gh issue view` to make this decision.** GitHub models a pull request as a kind of issue, so `gh issue view <n>` on a PR number *succeeds* and hands back the PR. Every number looks like an issue to it, which is why the discriminating question is the one asked above.

  • **A bare number on any other tracker** is a PR number. There every ticket reference carries a

prefix, so a bare number has nothing else it could mean.

Ticket to pull request

gh issue view <n> --json closedByPullRequestsReferences

That field only sees pull requests linked by a closing keyword. `csw:work` writes `Closes <TICKET>` **or** `Refs <TICKET>`, and a `Refs` body links nothing at all — so an empty result is not yet an answer. Search before concluding there is no PR:

gh pr list --state open --search "<TICKET>" --json number,title,baseRefName,headRefName

Then say which reading you used

Before anything is merged, **say which reading you used** and on what basis — "PR #92, from issue #92", or "PR #92, named directly". A merge is one-way, and naming the object out loud is what lets someone stop the run while stopping is still free.

Stops

  • **No PR for the current branch**, on a bare invocation. Say so and stop.
  • **No PR for the ticket.** Say so and stop. Do not go looking for a plausible nearby branch.
  • **More than one candidate.** List them and ask which to merge. Never pick.
  • **The reference resolves to a PR that is not the current branch's PR.** Report both and ask.

Neither one silently wins. A reference gets stated precisely when several PRs are open, which is exactly the situation in which quietly preferring one would do the most damage.

  • **The PR is a draft.** Draft means the work told you it was not a merge candidate. Ask

whether to mark it ready first.

Then read what is left over: the rider

**Consume the known tokens first** — the reference Step 1 just resolved, and the phrasing Step 2 checks for. Then read whatever is left, by word count. `csw:work` parses its own invocation the same way; one grammar, both skills:

| Remainder | Reading | |---|---| | Nothing | No rider. | | **One word** | Suspected typo. Say what was passed, say it is not recognised, and ask. | | **Two or more words** | An **editorial rider**. Accept it. |

`go for merge — reviewed the ADR, all good` is the shape this exists for: `go for merge` is the green light Step 2 is looking for, and `reviewed the ADR, all good` is the rider. Splitting on word count keeps the reading mechanical, and therefore testable — it is not a judgement about whether something *sounds like* direction.

**A rider is echoed in the announce line, always:**

> Using csw:merge to land PR #92 — rider: "reviewed the ADR, all good"

A rider that quietly changes what a merge does is the failure this must not introduce, and a merge is one-way. Visible at the top of the run is the price of accepting it at all.

A rider is context, never authority

  • **It cannot green-light red CI**, skip a gate, or waive validation. **Step 3 is untouched:**

"CI is flaky, ignore the failing check" is named and refused, exactly as it would be without a rider. Red is still red.

  • **It cannot substitute for the diff, or for the ticket behind it.** A rider is a note in the

margin of what was reviewed, not a replacement for it, and it never stands in for reading the ticket.

  • **It is not the green light.** Step 2 is unchanged: an ambiguous approval still earns its one

clarifying question, and a rider riding along with a maybe does not turn it into a yes.

  • **A rider that contradicts the ticket, or a decision recorded in a `**CSW prep**` comment, is

named back and asked about** — not silently preferred, and not silently dropped. Prep's decisions carry their reasoning precisely so they can be overturned deliberately.

What a rider can do: review testimony

A rider is **review testimony**, and that is a real role rather than a consolation prize. It is the kind of thing a person says at the moment of merging, having just read the diff — and the ADR acknowledgment in Step 4 is the one gate in this skill whose entire ques

Read more
Ships withcsw

CSW takes a ticket from your tracker to a merged pull request, then cleans up after itself. Superpowers owns how the work gets done. CSW owns *how it gets shipped and closed out*. This is one person's idiosyncratic workflow, and it is probably not yours.

Get the whole plugin
Stats
3
Stars
0
Forks
Active
Maintenance
Shell
Language
MIT
License
6d ago
Last commit
11mo ago
Created

Repo: mikestankavich/claude-ship-workflow

Other skills on csw.

prep
Skill

prep

Spec a ticket before it is dispatched. Brainstorms it, decides everything it can recommend an answer for, asks a present human about the little that survives,…

work
Skill

work

Dispatch a tracker ticket into an isolated worktree and drive it autonomously to an open pull request, then stop for review. Pass `interactive` to brainstorm…