batch
Dispatch a night's batch of Todo tickets — one worktree and one pull request each — and leave a morning summary. Run explicitly; never inferred.
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.
$ npx -y skills add mikestankavich/claude-ship-workflow --skill merge --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/mergeContext 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.
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]"
**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>"`.
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.
below.
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.
prefix, so a bare number has nothing else it could mean.
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
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.
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.
whether to mark it ready first.
**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.
"CI is flaky, ignore the failing check" is named and refused, exactly as it would be without a rider. Red is still red.
margin of what was reviewed, not a replacement for it, and it never stands in for reading the ticket.
clarifying question, and a rider riding along with a maybe does not turn it into a yes.
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.
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
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.
Dispatch a night's batch of Todo tickets — one worktree and one pull request each — and leave a morning summary. Run explicitly; never inferred.
Clean up after a merged pull request — return to the base branch, remove the worktree, delete the branch, sweep other stale branches and worktrees, and report…
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,…
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…