---
description: Execute a Jira solo-tasker handoff plan using Jira as workflow state and jj workspaces for implementation isolation. Use when handed a plan that names this skill.
polytoken:
  tags: [jira-solo-tasker, workflow, jira, jj]
---

# Jira Solo Tasker Execute

Use this skill in the execute facet on a plan produced by `jira-solo-tasker-plan`.

Reinforce this procedure even if the handoff plan repeats it. If the handoff conflicts with this skill, stop and ask the operator unless the difference is clearly project-local configuration.

## Source of truth

Jira is both the human source of truth and the agent working truth for this workflow when Jira tools are available and permitted.

Use the Jira issue status, description, comments, and linked Confluence pages as durable workflow state. Update Jira at explicit gates. Local notes are optional support material, not the canonical state.

## 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`

These values are project contracts. If a transition fails or the board appears reconfigured, re-verify with `getTransitionsForJiraIssue` and ask the operator before substituting IDs.

## Procedural checklist

### 1. Confirm the Jira claim

The plan skill should already have moved the ticket to In Progress.

- Verify the issue with `getJiraIssue`.
- Confirm status is In Progress.
- Confirm there is a plausible `Claimed by solo-tasker` comment or other operator-approved claim context.

If the issue is not In Progress, do not re-claim blindly. Surface it to the operator.

### 2. Create or enter a jj workspace

Use the exact workspace/bookmark name from the handoff plan, normally:

```text
pm-<number>-<short-description>
```

This workflow uses jj workspaces, not Git worktrees. Do not use `.worktrees/`, `git -C .worktrees`, `git merge --squash`, or `.merge-lock` unless the project explicitly overrides this skill.

First inspect project instructions for a workspace wrapper. If one exists, use it. Otherwise use generic jj commands. After creating or entering the workspace, always start a fresh change with `jj new -m ...` before editing; otherwise work may be smushed into the current jj change.

Suggested generic flow:

```sh
root="$(jj workspace root)"
jj workspace list
workspace_path="$(dirname "$root")/<workspace-name>"
jj workspace add "$workspace_path" -r @
cd "$workspace_path" && jj new -m "<ticket-key>: <summary>"
```

Important shell rule: every shell call starts fresh. Use the absolute workspace path from setup for every workspace command; do not rely on relative paths like `../<workspace-name>`, and do not assume a previous `cd` persisted.

```sh
cd "$workspace_path" && <command>
```

For file tools, use paths in the active project checkout unless the harness has permission to access the sibling workspace. If file tools cannot write the sibling workspace safely, stop and ask whether to continue in the current checkout or adjust permissions.

### 3. Track todos around the whole workflow

Make sure the todo list covers:

- Jira claim verified;
- jj workspace created/entered and fresh ticket change started with `jj new`;
- implementation;
- formatting/build/tests;
- implementation review loop;
- jj describe/squash/bookmark as appropriate after work is already isolated in the ticket change;
- Jira moved to In Review;
- operator acceptance;
- Jira moved to Done or returned for changes.

### 4. Implement the plan

Follow the handoff plan and ticket acceptance criteria. Keep changes minimal and ticket-scoped.

If new information changes scope or acceptance criteria, update Jira with a concise comment and ask the operator when product intent is involved.

### 5. Build and test

Run the project’s formatting, linting, build, and test commands from inside the jj workspace.

If the project uses `direnv`, run commands through `direnv exec .` from the workspace unless project instructions say otherwise.

Use the narrowest sufficient checks first, then broader checks if the change warrants them. Record exact commands and outcomes for the final report and Jira comments if useful.

### 6. Implementation review loop

Run the configured reviewer set. Default panel:

- `general-purpose` with `model_override` `codex/gpt-5.5(high)`
- `general-purpose` with `model_override` `anthropic/claude-opus-4-8(medium)`
- `general-purpose` with `model_override` `zai/glm-5.2(max)`

Ask reviewers for Critical/High/Medium/Low findings, with evidence and suggested fixes.

Fix or rebut every Critical/High finding with concrete evidence: code references, tests, docs, reproduction results, or Jira/Confluence references. Re-run targeted review while any unrebutted Critical or High finding remains.

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

Treat project-specific review guidance as authoritative where it exists.

### 7. Finalize the jj change

Before moving Jira to review:

1. Inspect the jj state and diff:
   ```sh
   jj status
   jj diff
   jj log --limit 10
   ```
2. Ensure the change description references the ticket:
   ```sh
   jj describe -m "<ticket-key>: <concise summary>"
   ```
3. If work was split into multiple granular changes, ask the operator whether to squash now or leave the stack as-is. For small solo-tasker work, prefer one clean described change unless the project wants a stack.
4. Create or move a bookmark if the project uses bookmark-based push/review:
   ```sh
   jj bookmark create <workspace-name> -r @
   # or, if it exists and the operator/project agrees:
   jj bookmark set <workspace-name> -r @
   ```
5. Push only when the plan or operator asks for it:
   ```sh
   jj git push --bookmark <workspace-name>
   ```

Do not merge directly to `main` as part of this generic skill. Moving from In Review to Done happens after operator acceptance or the project’s review/merge process.

### 8. Move Jira to In Review

After implementation, tests, review, and jj finalization are complete:

- transition Jira to In Review (`31`);
- add a concise comment with implementation summary, validation, review status, workspace/bookmark, and anything the operator should check;
- prompt the operator to review the work.

### 9. Acceptance gate

Only after explicit operator acceptance or project-defined acceptance:

- perform any project-specific push/PR/merge/finalization steps the operator requests;
- transition Jira to Done (`41`);
- optionally comment with final verification and where the work landed.

If the operator rejects the work, address feedback, keep or return the ticket to In Progress as appropriate, and repeat from implementation/review.

### 10. Report

Final response to the operator:

- restate ticket key and summary;
- summarize what changed;
- list validation commands and results;
- list reviewer status and unresolved follow-ups;
- state Jira status;
- state jj workspace/bookmark/change information;
- give concrete advice for testing or reviewing the result.

## Cancellation

If the operator cancels mid-execute, ask whether to leave the ticket In Progress or transition it back to To Do (`11`). Do not abandon jj changes or delete a workspace without explicit confirmation.
