---
description: Find, claim, research, and plan a small Jira task using Jira as the workflow source of truth. Use when the operator asks you to pull a ticket, find something small to work on, or prepare an execute handoff from Jira.
polytoken:
  tags: [jira-solo-tasker, workflow, jira]
---

# Jira Solo Tasker Plan

Use this skill in the plan facet. Pick one small, eligible Jira task, claim it in Jira, research it, resolve material ambiguity with the operator, and produce a handoff plan that names the execute skill `jira-solo-tasker-execute`.

Do not implement anything.

## Source of truth

For this workflow, Jira is both the human source of truth and the agent working truth when Jira MCP/tools are available and permitted.

The ticket status, claim comment, description, comments, linked Confluence pages, and transition history are durable workflow state. Local Markdown is optional support material only; do not create a separate local issue tracker unless the project explicitly asks for one.

## Project configuration

Default project settings for this repository:

- Atlassian cloudId: `eab0a222-1a38-4539-a21d-44fb3466b28b`
- Jira project: `PM`; Confluence space key: `PM`, numeric space ID: `98315`, overview/root page ID: `98479`
- Transitions: To Do `11`, In Progress `21`, In Review `31`, Done `41`
- Eligible issue types: Task (`10007`), Bug (`10009`)

These are project contracts, not universal workflow defaults. If a configured project variable, setup note, or ticket contradicts this section, stop and ask the operator which source is current. Re-verify transitions with `getTransitionsForJiraIssue` if the board was reconfigured or a transition fails.

## 1. Scan for candidates

Run one Jira search first; do not build a clever query before seeing the board shape.

Use `searchJiraIssuesUsingJql` with:

```jql
project = PM AND status = "To Do" ORDER BY priority ASC, created ASC
```

Request fields:

```json
["summary", "description", "issuetype", "priority", "labels", "status", "parent", "issuelinks", "comment"]
```

Then filter in context. A candidate is eligible only if all hold:

- issue type is Task or Bug;
- no `no-auto` label;
- no Epic parent and not a Subtask;
- not blocked by unresolved work: no `issuelinks` entry with `type.name == "Blocks"` that has an `inwardIssue` whose status is not Done;
- moderate-to-small scope;
- the summary/description plus codebase research are enough to form an implementation plan.

Prefer higher priority and older issues; the JQL ordering already approximates this.

If nothing qualifies, say so and stop. Do not claim marginal work just to stay busy.

## 2. Claim the chosen issue before deep research

Pick the best candidate. Read it in full with `getJiraIssue`, fields `["*all"]`, content format Markdown. This is the baseline research read.

Use a two-layer claim guard:

1. If the issue is already In Progress, or a recent comment matching `Claimed by solo-tasker` from another session exists, back off and pick the next candidate.
2. Otherwise claim it:
   - `transitionJiraIssue` with transition `{id: "21"}`;
   - `addCommentToJiraIssue` with body `Claimed by solo-tasker plan run <session-id> at <ISO time>.` Use the session identifier and current timestamp available in context.

The claim happens in planning, not execution. This avoids duplicate parallel work. Because the claim is a side effect, unattended runs require permissions for `transitionJiraIssue` and `addCommentToJiraIssue` in the plan facet; otherwise the operator will be prompted.

## 3. Research and clarify

Investigate the codebase before asking factual questions. Read relevant modules, tests, commands, and project instructions. Confirm:

- touched files and contracts;
- likely tests/checks;
- build or dev environment requirements;
- any Confluence links or Jira comments that affect scope;
- whether the work is small enough for this workflow.

Use `ask_user_question` only for product intent or decisions that materially change implementation. Do not guess on behavior, acceptance criteria, or scope.

If research shows the issue is not viable for this workflow, release the claim: transition back to To Do (`11`) and leave a brief comment explaining why.

## 4. Write the handoff plan

Call `write_plan` with the standard plan-facet shape: Goal, Implementation Summary, Implementation Plan, Acceptance Criteria, Test Strategy, Review Strategy, Documentation Strategy, Risks.

The plan must:

- name `jira-solo-tasker-execute` as the required execute skill;
- reference the ticket key throughout, for example `PM-23`;
- state that Jira is the agent working truth for this workflow;
- state that the ticket is already In Progress and execute must verify the claim, not re-claim blindly;
- specify a concrete jj workspace name and bookmark name derived from the ticket, using the form `pm-<number>-<short-description>` with at most three kebab-case summary words;
- direct execute to create or enter a jj workspace for the ticket, not a Git worktree;
- include todos around the implementation: verify Jira state, create/enter jj workspace, implement, run formatting/tests, run the review loop, describe/squash the jj change as appropriate, move Jira to In Review, wait for operator acceptance, merge (usually via rebase) if approved, then move Jira to Done;
- encode the shared review gate: run the configured reviewer set, fix or rebut every Critical/High finding with evidence, and re-run targeted review until zero unrebutted Critical/High findings remain;
- include final reporting expectations: restate the ticket key and summary, summarize changes, list validation performed, and give concrete operator test advice.

### jj workspace guidance for the plan

Use jj terminology consistently:

- workspace: isolated checkout created with the project’s configured workspace creation wrapper or `jj workspace add`;
- change: rename the change with the right context for the ticket work with `jj desc -m "<ticket-key>: <summary>"` before any edits;
- bookmark: optional named ref for pushing/sharing, normally the same slug as the workspace.

Do not mention Git worktrees, `.worktrees/`, `git merge --squash`, or `.merge-lock` unless the current project explicitly uses those. This workflow defaults to jj workspaces.

If the repo has a project wrapper for workspaces, cite it. Otherwise specify generic jj commands and make execution verify them. The handoff will start on a fresh change after workspace creation, and individual internal tasks should use `jj new -m` to create new, labeled changes before starting a chunk of work; `jj describe` is only for updating an already-isolated change later.

```sh
root="$(jj workspace root)"
workspace_path="$(dirname "$root")/<workspace-name>"
jj workspace add "$workspace_path" -r @
cd "$workspace_path" && jj desc -m "<ticket-key>: <summary>"  # optional after this: jj bookmark create <workspace-name> -r @
```

The exact parent directory for sibling workspaces is project policy. If not obvious, require execute to ask before creating one.

## 5. Heavy plan approval loop

Before `handoff_plan`, run three `plan-reviewer` subagents in parallel with the configured/pinned models:

- `codex/gpt-5.5(medium)`
- `umans/umans-kimi-k2.7`
- `zai/glm-5.2(max)`

Fix or rebut every plan finding with evidence. Re-run the same reviewer set while any reviewer returns any Critical or High finding.

If a pinned `model_override` does not resolve at runtime, stop and ask the operator. Do not silently substitute a weaker model and weaken the approval gate.

Only call `handoff_plan` when all reviewers report zero Critical and zero High findings, or when the operator explicitly accepts the risk.

## 6. If the operator cancels

If the operator rejects the handoff, cancels the work, or you judge the issue unviable, release the claim unless the operator says to keep it In Progress:

- transition Jira back to To Do (`11`);
- leave a concise comment if useful;
- do not leave issues stranded In Progress.
