Skip to main content
Version: 0.8.4

Task Lifecycle — Phase 2: Implement

Phase 2 of the task lifecycle, run by the jira-task-executor skill. Triggered once per leaf issue, from inside its own worktree. Multiple executors run in parallel against the worktrees the assigner set up.

The diagram surfaces the two systems the executor drives as their own swimlanes — GIT (anything that mutates repo state: reading the worktree's branch and parentbranch config, merging the parent branch current, committing, pushing, opening the PR) and JIRA (anything that mutates issue state: fetching the issue and its prior comments, the In Progress / In Review transitions, any Task memory comments posted along the way, and the final run-report comment) — so the full interaction reads User ↔ Executor ↔ GIT ↔ JIRA left to right.

Sequence diagram​

What the diagram shows​

  • Participant routing — the executor orchestrates between three parties. GIT owns repo state (the worktree-ownership read, merging the parent branch current, the commit, the push, and the PR open). JIRA owns issue state (the issue fetch that carries the parent family and prior comments used in the ownership check and task-memory read, the In Progress and In Review transitions, any Task memory comments posted along the way, and the final run-report comment). Everything else (investigating, clarifying, implementing, testing) stays inside the executor.
  • Parallel lanes — the par / and / end block encodes the worktree-level parallelism the assigner's phase 1 setup makes possible. Every leaf has its own worktree and can run concurrently.
  • Uniform path — the executor validates its worktree (GIT), brings its branch current, commits, pushes, opens a PR (GIT), transitions to In Review (JIRA), and posts its run-report comment (JIRA). The PR is the thing phase 3 reviews.
  • Status transitions the executor owns — to In Progress on start, to In Review on PR open (both JIRA). Each is skipped when the issue already reads that status: workflows generally offer no transition into the status an issue already occupies, so asking anyway exits 8, and a non-zero jira.sh result is a stop condition. That matters most on a re-run after a reject — the reviewer has already put the issue back to In Progress, and aborting there would end the run before it ever read the reviewer's findings.
  • Task memory is a first-class JIRA interaction, not a single comment invariant — the executor reads prior Task memory (jira-task-executor) comments as part of the step-1 fetch, and may post its own as investigation/implementation turns up findings worth preserving (the opt block — zero or more per run, not fixed). These are expected companions to the one comprehensive run report posted after the In Review transition (PR URL, branch, final status) — the invariant is "one run report per run," not "one Jira comment per run."
  • Identity first, then ownership — before anything else, the executor authenticates as itself (per-request --role executor), so every Jira write in the run — the In Progress and In Review transitions, the task-memory notes, the run report — is attributed to the executor account rather than to whoever happened to be logged in. It then gates on ownership (check_assignee.sh): <KEY> must be assigned to that account. Anything else — unassigned, assigned to someone else, unreadable — stops the run before it has touched anything, printing the ready-to-paste jira.sh issue assign … command. This is the counterpart to phase 1 assigning every issue to the executor on create: the assigner says who owns the work, and the executor refuses to work anything it doesn't own. (Ownership is compared by accountId, not by email — Jira only exposes an assignee's emailAddress to that user themselves, so an email comparison cannot tell "someone else's" from "unassigned". See plugins/jira-sdlc/skills/_shared/jira-api-reference.md §10.)
  • Guards before work starts, and along the way — the executor validates that its worktree actually belongs to <KEY> (or its parent family) by reading GIT before doing anything, and if <KEY> turns out to be a multistep parent it asks the user to confirm rather than silently implementing on it. Two more guards can stop the run mid-flow: a merge conflict while bringing the branch current (GIT), and a test that still fails when re-run individually after the suite run (both leave the run stopped, with no commit/push/PR).