# Mpt Ext Task Move Jira To QA

> Only transition one issue's Jira status to its correct post-merge state (QA or Done) after merge. Resolves the target from issue and repo context; usually called by the complete-after-merge workflow.

- Skill: `softwareone-platform/mpt-ext-task-move-jira-to-qa` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add softwareone-platform/mpt-ext-task-move-jira-to-qa`
- Raw SKILL.md: https://api.skillmd.com/api/skills/softwareone-platform/mpt-ext-task-move-jira-to-qa/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: softwareone-platform (https://skillmd.com/u/softwareone-platform)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/softwareone-platform/mpt-ext-task-move-jira-to-qa

---


# Move Jira After Merge

## Purpose

Move a Jira issue into the correct post-merge Jira status after the reviewed pull request has been merged.

## Use When

- The user wants to complete the development flow after merge.
- The task requires transitioning a Jira issue from review-complete state to its post-merge Jira status.
- The pull request has already been merged or the user explicitly confirms the work is in post-merge state.

## Do Not Use When

- The task is to start work and move Jira issues to `In Progress`.
- The task is to hand work over for review and move the issue to `Code Review`.
- The task is to create or update a pull request.
- The task is to process PR review comments.

## Inputs

- Jira issue key.
- Confirmation that the relevant pull request was already merged.
- Optional repository-specific post-merge target status when local docs define one explicitly.
- Installed shared package root when shared package guidance is needed:

```text
${MPT_EXTENSION_SKILLS_HOME:-$HOME/.mpt-extension-skills}/current
```

## Assumptions

- Jira authentication is available and the target issue can be read and transitioned through `mpt-ext-tool-jira-workitem-ops`.
- The repository workflow exposes a usable transition into the correct post-merge status for the issue type.
- The corresponding pull request has been merged, or the user explicitly confirms the work is in post-merge state.

## Workflow

1. Build repository context first.
- Read the target repository `AGENTS.md` once per session. If you already loaded it earlier in this session and still have its full contents, reuse them instead of re-reading; if the context was summarized or you are unsure it is complete, read it again. Do not pre-load shared docs in this step; read them lazily only when the repository points to them.
- Read repository-specific docs when they exist, because they may extend or override shared guidance.
- Read shared docs only when the repository explicitly points to them. Resolve those shared docs from `${MPT_EXTENSION_SKILLS_HOME:-$HOME/.mpt-extension-skills}/current` when available; otherwise read them from the `main` branch of the shared GitHub repository.

2. Read the Jira issue first.
- Use `mpt-ext-tool-jira-workitem-ops` to fetch the current issue state.
- Confirm the issue exists and identify its current workflow status and issue type.

3. Verify post-merge readiness.
- Confirm the relevant pull request was already merged.
- If merge state is unclear from the current workflow context, ask the user before moving the issue.
- If the work is still under review or not yet merged, stop and explain that the issue should not move to a post-merge status yet.

4. Resolve the target post-merge status.
- Follow repository-specific Jira workflow or post-merge handoff docs when they define the target status explicitly.
- If the Jira issue is a subtask, default the target status to `Done`.
- Otherwise default the target status to `QA`.
- If the issue is already in the resolved post-merge target status, preserve the current state rather than rewriting it unnecessarily.

5. Transition the issue to the resolved post-merge status.
- Use `mpt-ext-tool-jira-workitem-ops` to move the Jira issue to the resolved target status when it is not already there.
- If the resolved target status is not allowed by the actual Jira workflow, stop and report the blocker instead of guessing another status silently.

6. Report the result clearly.
- State which post-merge target status was selected.
- State whether the issue moved to that status.
- State whether the issue was already in that status.
- Show blockers clearly when Jira workflow rules, permissions, or missing merge confirmation prevent completion.

## Guardrails

- Never move the issue to a post-merge status before the relevant PR is merged.
- Never assume merge completion when the workflow context is ambiguous.
- Never hard-code `QA` for subtasks when their workflow should end in `Done`.
- Never rewrite already-correct Jira state without need.
- Never mix merge execution, PR comment handling, or branch operations into this task.

## Expected Outcome

The Jira issue is in the correct post-merge status once the reviewed work is merged, or the task stops with a clear blocker that explains why the issue should not move yet.