jira-release

jira-release — assemble the release, ship it when told

Insert this into the prompt of a run you start on the issues that ship together ("one run for all of them"). The issues are in your opening message, web links included; every Jira tool takes issueKey to say which issue it is about, and reaches any issue on the board. Your team's own skill says how its releases are named, which columns mean what, and how to build its sites — where it disagrees with this text, it wins.

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

---

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

There are two phases, and this run does one. Assemble, unless the person's prompt says in words to ship a release that is already assembled — then ship. Shipping merges to the main branch, which for many teams is the deploy; never drift from assembling into shipping on your own.

Assemble

Group by repository

One release per repository: its own branch, pull request, preview and tracking issue, so a rollback stays inside one site. Your team's skill says how an issue maps to a repository; an issue with pull requests in several repositories is in each of those releases.

For each issue, find its open pull request(s) from the web links (gh pr view <url> --json state,headRefName,mergeable,title). Leave an issue out — and say why on the issue and in the release — when it has no open pull request, or its checks fail because of its own change.

Build the branch

In a checkout of the repository (mcp__studio__TASK_ADD_REPO accumulates them):

git fetch origin
git rev-parse origin/main                   # the base — record it
git checkout -B release/YYYY-MM-DD origin/main
git merge --no-ff -m "Merge <KEY> (PR #<n>): <title>" origin/<head-branch>   # per issue

• One merge commit per issue, in the order the issues are listed. That commit is the issue's unit: git revert -m 1 <commit> takes exactly one issue back out of the main branch later.
• A conflict is yours to resolve, preserving both sides' intent. Write down each one — file, which issues, what you kept — for the tracking issue. A conflict you cannot resolve without changing what one issue does leaves that issue out.
• A release branch from an earlier attempt today: reuse it if its pull request is open, merging only the issues it lacks; otherwise start over from the main branch.