Skip to main content
Version: 0.8.4

Task Lifecycle — Phase 1: Plan

Phase 1 of the task lifecycle, run by the jira-task-assigner skill. Triggered once per task, invoked from the default base branch (or from the production branch, which is accepted only for an emergency hotfix) — the assigner refuses to run on an existing feature//hotfix/ issue branch or from a detached HEAD (which gives the new branches nothing nameable to be cut from), and asks the user how to proceed on any other branch.

This phase ends when the assigner reports back: issues exist, branches and worktrees are ready, a "PR target branch: ... Worktree: ..." comment is posted on every leaf issue (plus one more on the parent issue itself in the multistep case) for the next phase to read, and the report itself is posted as a Jira comment on the parent issue in addition to the chat reply.

The diagram surfaces the two systems the assigner actually drives as their own swimlanes — GIT (anything that mutates repo state: reading the current branch, creating branches, setting parentbranch config, pushing, adding worktrees) and JIRA (anything that mutates issue state: creating the top-level or sub-task issue, posting comments) — so the full interaction reads User ↔ Assigner ↔ GIT ↔ JIRA left to right.

Sequence diagram​

What the diagram shows​

  • Participant routing — the assigner is the orchestrator between three parties. GIT owns repo state (the initial branch-context read, branch creation, the branch.<branch>.parentbranch git config entry, the push, and git worktree add). JIRA owns issue state (creating the top-level or sub-task issue — the sub-task carries its parent link — and posting the durable PR target branch comment). Everything else (investigating the codebase, deciding scope) stays inside the assigner.
  • Two identities, and they are not the same one — the assigner authenticates as itself (per-request --role assigner) before anything else, so Jira records it as the creator and reporter of every issue here — both are derived from the authenticated account, no flag needed. But each issue is assigned to the executor (get_assignee_email.sh → --assignee on every create, top-level and sub-task), because the executor is who will pick it up — and phase 2 refuses an issue that isn't assigned to it. So the board reads correctly end to end: filed by the assigner, owned by the executor. Both identities come from that role's own required credential pair — there is no default account either can fall back to. See plugins/jira-sdlc/skills/_shared/project-config.md.
  • Investigate + clarify loop — the only place the user is asked anything by jira-task-assigner; questions persist until scope, acceptance criteria, and priority are settled. (The branch-context "ask otherwise" path, if triggered, is also a user question.)
  • Scope decision first — the assigner settles scope and the top-level type (alt Multistep / else Single-step); inside the multistep loop it provisions each sub-task's issue (JIRA) then branch
    • worktree (GIT) uniformly.
  • The base decision rides along with scope — planned work (the default) branches feature/ off development, while an explicitly requested emergency production fix branches a single hotfix/ off origin/main (SDLC.md §4). Because it cuts from the fetched remote ref rather than checking production out, the hotfix works the same whether you invoke it from development or from main — main is a permitted start state, never a required one, and step 5C stops if it turns out to be planned work. Either way the Multistep arm is always the planned path, and the two never mix within a run.
  • Provisioning is uniform — every scenario (single-step, multistep parent, sub-task) records branch.<branch>.parentbranch in git config via GIT, pushes the branch to the remote via GIT, and ends with the assigner posting a PR target branch: ... Worktree: ... comment to JIRA for that leaf — the durable source of truth the executor and reviewer will read later. In the multistep case this happens once per sub-task and once more on the parent issue after the sub-task loop, so it's neither one-per-leaf nor a single comment overall.
  • The final report is durable too — before deactivate Assigner, the report goes to JIRA as a comment on the parent issue in addition to the chat reply to the user, so a later phase (or a fresh session) can recover it without relying on chat history.

The assigner deliberately stops short of writing any code, commits, or PRs — those are phase 2's job.