teamcraft-glgd:post-merge

What this skill does

## Goal

After a merge to the default branch: confirm the GitLab issue is closed and labels are clean, then get the developer's local environment synced. The developer should leave this skill with a closed issue, clean labels, and a clean local default branch.

## Hard Constraints

- Assess the full local state before proposing anything — never touch git without first knowing what's there.
- Present each proposed action with a plain-English explanation of what it does and why before running it. Wait for approval.
- Never force push. Never reset --hard. Never delete a branch without the developer's explicit confirmation. Never try to resolve merge conflicts automatically.
- If the developer has uncommitted changes, staged or unstaged, stop and surface that before anything else. Losing uncommitted work is unrecoverable.
- Branch deletion must be offered as a command for the developer to run themselves if a safety hook is in place that blocks Claude from running it. Provide the exact command.
- When updating labels, always fetch current labels first, merge the change, then update. Never replace all labels.

## Confirm GitLab State

Identify the project from `.teamcraft/project.md` or git remote context. Find the MR that was merged — either from the current branch name or by asking the developer which issue was just merged.

**Issue closure:** Fetch the linked issue. If it is not yet closed (the `Closes #IID` keyword in the MR description should have auto-closed it on merge), close it now via `mcp__gitlab__update_issue` with `state_event: "close"`. This is automatic — do not ask for approval, just do it.

**Label cleanup:** Fetch current labels on the issue. Remove "In Review" if present. Do not add a new label — a closed issue speaks for itself. Update labels silently as part of the same step.

Report: "Issue #[IID] is closed. Labels cleaned up." No fanfare needed.

## Assess Local Git State

Gather: current branch name, staged changes, unstaged changes, untracked files, how far behind origin/default the local branch is, and whether other local branches have uncommitted or unpushed work.

Present the full picture clearly before proposing anything.

Confirm: Is the MR for the current branch the one that was merged? If not, ask which branch's MR was merged and adjust accordingly.

## Propose and Execute Steps

Based on the assessment, propose what needs to happen: fetch and pull the default branch, delete the local feature branch (once it's confirmed as merged), update dependencies if lockfiles changed, run tests to confirm the merged state is clean.

For each proposed action:
- Explain what the command does and why
- Explain the risk (most have none; be honest about the one or two that have edge cases)
- Wait for approval before running

Respect any answer. The developer may want only the pull. They may skip tests. Their call.

## Edge Cases — Handle Explicitly

- **Uncommitted changes on current branch**: Surface before any checkout. These are NOT lost by switching branches, but clarify that before the developer panics.
- **On the default branch already**: Skip the checkout step, just pull.
- **Merge conflict on git pull**: Stop completely. List the conflicting files. The developer resolves manually. Do not attempt automatic resolution.
- **Branch has unpushed commits (unexpected)**: Warn clearly before suggesting deletion. These would be permanently lost.
- **Multiple recent merges** (developer is several PRs behind): Normal. A single pull brings in all of them. Flag how many commits are incoming so it's not a surprise.

## Done

Summarize what was done. If a plan exists at `.teamcraft/plans/[IID].md` for the merged issue, note that it can be archived or left in place — plan files don't cause problems if left.