Merge

Skill yokeloop/yoke/skills/merge

Claude Code plugin and marketplace of skills & commands for the full dev loop: /task → /plan → /do → /review → /gca → /gp → /pr. Plus /prd, /issues, /explore, /grill, /bootstrap, /handoff and more.

Install

npx -y skills add yokeloop/yoke --skill merge

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

The user-triggered finisher that executes the post-PR tail per `.yoke/flow.md`: merges the task's PR(s), runs cascade merges, runs deploy/release commands, moves the ticket to its target state, cleans up worktrees, and returns to the default branch. Activates when the user writes "merge", "merge it", "/merge", "finish the task", "ship it", "cascade and deploy", or after the user approves a PR on GitHub. Never runs on its own — the merge decision stays the user's.

SKILL.md

3.1 KB, as published. Nobody here has run it

Finish the task: merge, cascade, deploy, transition, clean up

The flow ends at PR (ADR-0006): do drives every run to a ready pull request and stops there. The merge decision is the user's, made on GitHub. /merge turns that one decision into one command — it executes the whole post-PR tail per the flow map instead of the user dictating the same paragraph every session.

Principle: merging is the user's call; /merge runs only on the explicit word.

Input

$ARGUMENTS — optional PR URL(s) or a <slug>. Empty means the current branch/worktree's task: resolve its open PR(s) via gh (e.g. gh pr view, gh pr list --head <branch>).

Procedure

Read the flow map once at the project root:

bash ${CLAUDE_PLUGIN_ROOT}/lib/flow-read.sh

Then read and follow reference/merge-procedure.md — the one reference this skill routes to for the full mechanics. It runs this step sequence, each step skipped silently when the flow map does not declare it:

Merge PR(s) — merge the task's pull request(s) on GitHub.
Cascade — advance the branch cascade (e.g. master → staging → develop) by each declared step command.
Deploy / release — run the DEPLOY_COMMANDS the flow map declares, nothing inferred.
Ticket transition — move the task's ticket to its target state.
Worktree cleanup — remove the task's worktree(s) and delete merged branches.
Return to the default branch — sync and land on the repo's default branch.

Rules

Never auto-runs. /merge fires only on an explicit user command — no automatic trigger after do, ever. The merge decision stays the user's.
Skip undeclared steps silently. A step whose section is absent from the flow map is skipped without nagging — omission means "apply the default", never "fail".
Multi-repo. Merge every one of the task's PRs; libraries were already direct-pushed by do, so there is nothing to merge for them.
Git authorization comes from the skill invocation itself — see "Git initiative and defaults" in ${CLAUDE_PLUGIN_ROOT}/skills/gca/reference/commit-convention.md. Do not restate it; do not ask "merge?" mid-run.
Artifacts only under .yoke/.
Any fork — an ambiguous PR set, a merge conflict, an unclear target — is one AskUserQuestion with a recommended option listed first.
Language: match the ticket/input language, or follow the project-level definition in CLAUDE.md / AGENTS.md.

Notify

On finish, send the terminal STAGE_COMPLETE notification with what was merged and deployed — the exact call lives in reference/merge-procedure.md §7.