Merge Advance

---
name: merge-advance
description: >-
  Commit the current milestone unsigned, merge its slice stack into main
  bottom-up, delete the branches and prune the worktree, then update the
  milestone's issue and project status. Use when the user asks to land a
  finished milestone locally.
---

# merge-advance — land a milestone locally and update tracking

Closes out a finished milestone: commit unsigned, merge to `main`, clean up
the branch and worktree, then record the landing on the milestone's issue and
project. Run this only after the milestone is implemented and the gates are
green (see the `milestone` and `milestone-review` skills).

## Preconditions

- The gates pass on the branch (run the `gates` skill first if unsure — never
  merge red).
- You are on a milestone slice branch, not on `main` itself. A milestone
  delivered as a stack (see the `milestone` and `pr-handoff` skills) lands
  bottom-up: merge the bottom slice, then the next, never an upper slice
  before the ones below it.
- The milestone's GitHub issue is known (explicit URL/number from the user or
  task; otherwise resolve per the `github-workflow` skill — unique
  unambiguous match only, otherwise ask).

## Steps

1. **Commit — unsigned.** Commit the milestone work with a clean, concise
   message describing the milestone. Commits are NEVER signed: do not add a
   `Co-Authored-By` trailer or any "generated with" footer. Commit in logical
   chunks if the change is large. Exclude transient files the user does not
   want committed (e.g. `idea.md`, harness run state) when they say so.
2. **Merge into `main`, one slice at a time, bottom-up.** For each slice:

   ```bash
   git switch main
   git merge --no-ff zajca/<milestone-slug>   # or fast-forward if that is the repo's habit
   ```

   Resolve conflicts if any; re-run the `gates` skill on `main` after a
   non-trivial merge. When the stack is published as PRs, merge them on
   GitHub in the same order and retarget the next PR to `main` after each
   merge (`gh pr edit <n> --base main`) — the repository does not delete
   head branches on merge, so GitHub does not retarget it for you.
3. **Delete the branch and prune the worktree.** Everything should now live in
   `main`:

   Worktrees live in `pohunek-worktrees/` beside the primary checkout, so
   derive that from git instead of a relative path, which resolves only from
   the primary checkout. Run this from any checkout except the one being
   removed (or pass the absolute path `scripts/worktree-new` printed):

   ```bash
   primary=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)")
   git -C "$primary" worktree remove "$(dirname "$primary")/pohunek-worktrees/<milestone-slug>"
   git -C "$primary" branch -d zajca/<milestone-slug>
   git -C "$primary" worktree prune
   ```

   If the user asks to "vyčisti worktrees, všechno by mělo být v main", verify
   with `git worktree list` and reconcile any stragglers.
4. **Record the landing on the issue.** Via the `github-workflow` skill, post
   a comment with the merge commit and the final gate evidence. A local merge
   without an authorized push is not a landing for any repository change
   (code, scripts, docs, skills, config): keep the issue open at `In
   Progress` and record the local merge commit as evidence instead of closing
   it. Close the issue as completed and set the project to `Done` only when
   the landing of the whole stack on the remote default branch is verified
   (and its DoD met); a landed lower slice is a progress comment, not
   closure.
   Verified out-of-scope follow-ups discovered during the milestone go to
   their own issues, never into this one's scope; never move an unmet original
   DoD item to a follow-up to claim the milestone done. Verify every write
   from the API response.
5. **Set up the next work.** There is no next `NEXT.md`. If the next
   milestone is not yet planned, hand over to the `plan-phase` skill (its plan
   lands as a GitHub issue) instead of guessing.

6. **Report.** State the merge commit, that the branch/worktree are cleaned
   up, and the issue/project updates (verified landed).

## Constraints

- Push only when the user asks. This project keeps `main` local unless a push /
  release is requested.
- Never sign commits; no `Co-Authored-By`, no generated-by footer.
- Issue/project writes follow the `github-workflow` skill's safe-persistence
  rules; permission or network errors block the sync and are reported
  honestly, never papered over.
- Do not release here — cutting a version is the `release` skill's job.