Orchestrate Jira Issue

orchestrate-jira-issue

Validates a Jira issue, runs a planning sub-session that produces Trellis tasks, then runs an implementation sub-session that opens a PR.

Usage

/orchestrate-jira-issue <issue_id>

If <issue_id> is not provided, ask for it with AskUserQuestion before proceeding.

Ordering Constraint (load-bearing)

Always arm a Monitor on s2cLogPath BEFORE calling any launch tool. The sub's first message (hello) is the only liveness signal — it is written immediately after the sub boots. Because tail -n 0 discards all lines written before the tail is armed, arming the Monitor even slightly after the launch call will silently miss the handshake, causing the conductor to hang waiting for a message that was already dropped.

Workflow

Phase 0 — Configuration check

Required keys: atlassianBaseUrl, atlassianCloudId, jiraProjectKey.

1. Call mcp__plugin_jira-issue-orchestration_issue-orchestration__get-config with no arguments.
2. If any of atlassianBaseUrl, atlassianCloudId, or jiraProjectKey is missing or empty in the returned values, stop with: Config missing or incomplete. Run /configure-jira-orchestration to set it up, then re-run this skill.
3. Bind CLOUD_ID ← atlassianCloudId for the getJiraIssue call in Phase 1.

Phase 1 — Initialization

Execute these steps in order; each is a prerequisite for the next.

1. Claim conductor channel
   Call mcp__plugin_jira-issue-orchestration_issue-orchestration__claim-conductor, optionally passing label (e.g., the Jira issue key).
   Store the returned channelId, c2sLogPath, and s2cLogPath. Hold channelId for the entire run — do not call claim-conductor again.

2. Arm persistent Monitor (must happen before any launch)
   Start a persistent Monitor on s2cLogPath:

   Monitor({ persistent: true, command: "tail -n 0 -F <s2cLogPath>" })
   

   Do not proceed to the Jira fetch or any launch until this Monitor is running.

3. Validate Jira issue
   Fetch the issue via mcp__plugin_atlassian_atlassian__getJiraIssue using the provided key.
   If the issue status is Done, Cancelled, or Closed, stop and inform the user — do not proceed.

Phase 2 — Planning

1. Launch planning sub-session
   Invoke conduct-orchestration-team --team-type planning --channel-id <channelId> --additional-instructions <issue_id> via the Skill tool, where <issue_id> is the Jira issue key from Phase 1.
   conduct-orchestration-team manages the full planning sub lifecycle (launch → hello → instructions → done → terminate). Wait for it to return before proceeding.

2. Capture and verify the Trellis scope
   Parse scope=<TRELLIS_ID> out of the planning sub's done message (forwarded by conduct-orchestration-team Step 5). Bind the value as TRELLIS_SCOPE. If the token is absent or empty, stop and inform the user — the planning sub failed its contract.
   Confirm the root issue exists by calling mcp__plugin_task-trellis-teams_task-trellis__get_issue({ id: "<TRELLIS_SCOPE>" }). If get_issue returns no issue, stop and inform the user.
   Confirm there is implementable work under it: call mcp__plugin_task-trellis-teams_task-trellis__list_issues({ scope: "<TRELLIS_SCOPE>", type: "task", status: ["open", "in-progress"] }) and check the result is non-empty (when the root itself is a task, get_issue is sufficient — skip the list_issues check). If no open tasks are found under a non-task root, stop and inform the user — do not launch the implementation sub.

Phase 3 — Implementation

The planning sub was already torn down by conduct-orchestration-team. The channel and Monitor remain live — proceed directly with the implementation launch.

1. Launch implementation sub-session
   Invoke conduct-orchestration-team --team-type implementation --channel-id <channelId> --additional-instructions "<issue_id> scope=<TRELLIS_SCOPE>" via the Skill tool, where <issue_id> is the same Jira issue key from Phase 1 and <TRELLIS_SCOPE> is the root Trellis ID captured in Phase 2 step 2. Both values ride on a single line — do not embed newlines.
   Wait for it to return.

2. Confirm PR and report to user
   Run gh pr list --state open --limit 5 (via Bash) to confirm a PR was opened.
   Report the PR URL to the user.

Phase 4 — Final Teardown

Call mcp__plugin_jira-issue-orchestration_issue-orchestration__stop-orchestration-team({ channelId }) to tear down the channel, remove IPC directories, and clean up. This is called exactly once, at the very end of the run.

Key Constraints

• No conductor agent type. This skill runs in the user's existing Claude Code session. Do not define a new agent type.
• Monitor before launch. Always follow the Phase 1 ordering: claim → arm Monitor → fetch Jira. Never call launch-orchestration-team before the Monitor is armed.
• One channel for the full run. claim-conductor is called exactly once (Phase 1). The channel survives between phases — conduct-orchestration-team tears down each sub on its way out, and stop-orchestration-team({ channelId }) is called only once at the very end.
• One sub at a time. Phases run sequentially. Never invoke conduct-orchestration-team for a new sub before the previous phase has returned.