teamcraft-jcg:post-merge

---
name: teamcraft-jcg:post-merge
description: Sync advisor after a GitHub PR has been merged. Explicitly transitions the Jira issue to Done, cleans up stale Jira status, syncs local git state, and guides the developer through each step with explicit approval. Use when a PR was just merged, saying "just merged", needing post-merge cleanup, or when the Jira ticket is still open after merge. Also run when the local branch is stale after a merge, or when asking "what do I do after merge".
argument-hint: "(no arguments)"
disable-model-invocation: true
user-invocable: true
allowed-tools:
  - Bash
  - Read
  - AskUserQuestion
  - mcp__sooperset-mcp-atlassian__jira_get_issue
  - mcp__sooperset-mcp-atlassian__jira_transition_issue
  - mcp__sooperset-mcp-atlassian__jira_get_transitions
---

## Goal

After a merge to the default branch: explicitly transition the Jira issue to "Done" (this is mandatory — it cannot happen automatically via the PR), confirm the Jira status is clean, then get the developer's local environment synced. The developer should leave this skill with a closed Jira issue 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.
- **`Closes #N` in the PR description does NOT close the Jira issue.** GitHub closing keywords close GitHub Issues, not Jira issues. Explicitly transitioning the Jira issue to "Done" is a mandatory step — not optional, not a fallback.

## Confirm GitHub State

Identify the GitHub repo from `.teamcraft/project.md` or `git remote -v` via Bash. Find the PR that was merged — either from the current branch name via `gh pr list --head [branch-name] --state merged` via Bash, or by asking the developer which issue was just merged.

## Confirm Jira Issue Closure

Identify the Jira issue key. If running from a branch named `bug/PROJ-42-slug`, the issue key is `PROJ-42`. Otherwise, check `.teamcraft/project.md` or ask the developer.

Fetch the issue via `mcp__sooperset-mcp-atlassian__jira_get_issue`. Check its current status.

**If the issue is not yet in "Done" or "Closed" state:** This is the expected case — GitHub PR merge does not auto-close Jira issues. Fetch available transitions via `mcp__sooperset-mcp-atlassian__jira_get_transitions`. Transition the issue to "Done" (or the equivalent terminal state in this project's workflow) via `mcp__sooperset-mcp-atlassian__jira_transition_issue`. Never assume transition names — every Jira project has different workflow state names.

**If the issue is already in a "Done" or "Closed" state:** No action needed. Report that it is already closed.

Report: "Jira issue [PROJ-42] is now Done." No fanfare needed.

## Assess Local Git State

Gather via Bash: 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 PR for the current branch the one that was merged? If not, ask which branch's PR 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/[ISSUE-KEY].md` for the merged issue, note that it can be archived or left in place — plan files don't cause problems if left.