decocms / jira-merge

jira-merge — land it and move the cards

Insert this into the prompt of a run you start on several issues at once ("one
run for all of them"), or of the Jira column your team ships from. Either way
the issues are in your opening message, web links included, and every Jira
tool takes issueKey to say which issue it is about. On a run about one issue
you can leave it out.

It is ordinary text once inserted — read it, cut what does not apply to your
team, add what does.

You are landing work that has already been implemented and reviewed: the
issues above, each carrying its pull request(s) as web links.

Find what you are landing

• The pull requests are on each issue as web links. **An issue can carry more
  than one, in different repositories** — a change that spans two storefronts
  opens one in each, and both are the delivery.

• Ignore a link to a pull request that is already closed or merged, and links
  another team's automation left. gh pr view <url> --json state,mergeable
  tells you.

• An issue with no open pull request gets a comment saying so and nothing
  else.

Order

Merging one pull request moves the base under the next, so land them **one at
a time, in the order the issues are listed**, and re-check the next one's
mergeability after each merge rather than trusting what you read at the start.

Check before you merge

• Already merged? Say so in a comment and move on to the card. Do not
  re-merge, and do not open anything.

• Checks red? Read them (gh pr checks <url>, then the failing run's log)
  before deciding. A check that fails the same way on the base branch is not
  this change's fault — say that in your comment and merge. A check that fails
  because of this change is a stop for THAT issue: comment what broke, leave
  its card where it is, and carry on with the next issue.

• Blocked by branch protection or a missing approval? That needs a human.
  Report it on the issue and move to the next one; do not try to route around
  it.

Merge

• gh pr merge <url> from a checkout of THAT repository. A run can hold
  several (mcp__studio__TASK_ADD_REPO accumulates), and each is authenticated
  for its own host.

• A conflict is yours to fix. Check the branch out, merge the base branch
  into it, resolve preserving BOTH sides' intent, push to update the SAME pull
  request, then merge it. Never open a new one.

• All or none, when an issue spans repositories. Landing one half of a
  reciprocal change is worse than landing neither — it ships a declaration that
  only holds on one side. If you cannot land them all, land none, and say which
  one blocked you.

Report and move each card

Per issue, as soon as that issue is settled — not one summary at the end, which
a run that dies on the tenth issue never writes:

• mcp__studio__JIRA_COMMENT_ADD with issueKey — what merged, with the pull
  request links, and anything you decided (a red check you judged
  pre-existing, a conflict you resolved and how). This is the only record: a
  merge otherwise leaves no trace on the card.

• mcp__studio__JIRA_ISSUE_TRANSITION with issueKey — move the card to where
  your team puts shipped work, LAST, after the comment. If your team's flow
  ends before that column — some hand off with a comment and let the customer
  pull the card themselves — then say so in the comment and leave the status
  alone. Moving a card into someone else's column is a handoff they did not
  agree to.

• If anything is left undone on an issue, its comment says it plainly. A card
  that reads "merged" while half of it is still open is the one failure nobody
  catches.