merge

name	merge
description	Close out a feature branch or cs task worktree - run the repo's gates, merge --no-ff, re-run gates on the merged result, clean up. Invoke when the user asks to merge a branch or worktree, or to close out a finished feature.
disable-model-invocation	true

Merging is a ritual, not a git command: gates before, merge, gates after, cleanup only when everything is green. This skill closes out work that is already reviewed to the user's standard — it is the mechanical closer, not a quality gate or a review.

Prerequisites

• A clean tree. If git status --porcelain shows uncommitted changes, offer to commit them first; if the user declines, stop. Never merge over an uncommitted tree.
• A context (below). If neither applies — already on the default branch with nothing to merge — say so and stop.

Detect the context

1. cs task worktree: the workspace is a cs session named <base>@<task>, or git rev-parse --git-dir differs from git rev-parse --git-common-dir inside a cs-managed worktree session. The merge verb here is cs <base> --merge <task> — it fuses the session records, merges the branch, and removes the worktree. This skill wraps it with gates.
2. Feature branch: an ordinary checkout on a non-default branch. The target is the branch it forked from — usually the repo's default branch (git merge-base confirms ancestry); ask the user when the target is ambiguous.
3. Base session closing out a named feature: the workspace is the base session and the invocation named a feature (/merge fix-auth), which is what cs <base> -finish <feature> arms from the picker. The target is <base>@<feature>; run the preflight gates inside that worktree, then cs <base> --merge <feature> from here, then the post-merge gates in this checkout. Do not change directory into the feature session to merge — it cannot remove its own working directory.

When this skill is invoked with an argument, the argument is the feature name and context 3 applies. With no argument, detect the context from the workspace.

Discover the gates

Project instructions govern absolutely. Read the project's instruction files — CLAUDE.md and anything it imports, CONTRIBUTING.md, and the README's development section — for build steps, test commands, generated artifacts, and deploy steps. A repo that generates a file from source fragments needs its build run BEFORE tests and the generated file committed with the branch, exactly as its instructions say.

Without instructions, use the first conventional entry point that exists: tests/run_all.sh, a Makefile test target, package.json scripts.test, cargo test, go test ./..., pytest. If none exists, ask the user once for the gate command and use it for the rest of the conversation.

The ritual

1. Preflight gates on the branch (worktree context: inside the worktree): the build step first if the repo has one, then the full test gate. Everything green before anything merges.
2. Merge.
   • Feature branch: git checkout <target>, then git merge --no-ff <branch> with a merge message summarizing the feature.
   • Task worktree: cs <base> --merge <task> merges the branch, fuses the session records, and removes the worktree. Once the feature session is closed, run the verb from the base session — it merges while holding its own live lock, so no hand-off is needed. It still refuses two ways: running from inside the feature session, which cannot remove its own live working directory (close it and run from the base); and any other live base or feature lock. Run the post-merge gates in the base session afterward.
3. Gates again on the merged result (worktree context: in the base session checkout). A merge that was green on the branch can still break the target.
4. Cleanup: delete the merged feature branch with git branch -d — but not until the post-merge gates are green. The worktree verb already cleaned up its own.

When a gate fails

Diagnose it — that is why this is a skill and not a script. Find the root cause per the project's debugging rules, fix forward on the branch, and re-run the ritual from the top. A post-merge failure leaves the merge commit in place: report it with the failing output and let the user decide between fix-forward and revert. Never bypass, skip, or weaken a gate to make a merge pass.

After a green merge — offers, not actions

• If the project instructions document a deploy step, offer to run it (one question). Never deploy unprompted.
• In a cs session, offer /checkpoint <feature>-merged.

Never

• Never push, to any remote — publishing is the user's decision, made separately.
• Never merge over uncommitted changes.
• Never delete a branch until the post-merge gates are green, and never use git branch -D on unmerged work.
• Never bypass a failing gate or force a merge.