Repository navigation
feat(branch): move the Jira issue to in progress on --jira (#125) - #213
Conversation
…125) Reads the issue's status, reads its transitions only when the status category is new, and posts the one in-progress transition when the candidates lead to a single target. Nothing is written to an issue that has begun, is finished, or has no unambiguous target. Phase 1 of #125. Gate 1: pnpm check, both typechecks, build, test (2201), docs:test (69) and the marker grep all exit 0. Gate 2: FAIL on three unpinned rules, PASS after one loopback.
A personal, boolean, tri-state key beside jira.autoAssign: true always, false never, unset asks once and saves. Validated, ignored with the existing warning in a project file, prompted behind the Jira confirm, and documented where the other start keys are. Nothing reads it until the next phase wires --start for --jira. Phase 2 of #125. Gate 1: pnpm check, both typechecks, build, test (2222), docs:test (69) and the marker grep all exit 0. Gate 2: PASS WITH NOTES, then PASS WITH NOTES on a follow-up closing two of those notes.
branch --jira now moves a To Do issue to in progress once the worktree exists, by --start, --no-start and jira.autoStart, and reports it in started. A non-interactive run with the key unset moves the issue and saves nothing, as for Linear and ClickUp. A failed move warns and the worktree is still created. Nothing happens on a reopen or a dry run. The release note is left to /feature-close, per context/release.md. Phase 3 of #125. Gate 1: pnpm check, both typechecks, build, test (2239), docs:test (69) and the marker grep all exit 0; a one-sentence docs fix after Gate 2 ran lint and a read of the diff. Gate 2: FAIL on one unasserted message, PASS WITH NOTES after one loopback.
![baldurs-reviewer[bot]](https://avatars.githubusercontent.com/in/5381869?s=60&v=4){kind=small}
There was a problem hiding this comment.
code-reviewer: looks good
This adds startJiraIssue, which moves a To Do-category issue through the single in-progress transition its workflow offers. It also adds the jira.autoStart key (validated, prompted, personal-only in .worktree.yml), wires --start/--no-start for --jira in branch alongside Linear and ClickUp, and updates the docs, skill and changeset. I found no defects. The work goes by status category rather than name, refuses an ambiguous or absent target before writing, shows only integration-composed Jira: errors so a header-bearing fetch error cannot leak the token, and runs after the worktree exists without affecting the exit code; tests cover each outcome and the ordering. One thing to weigh before release: existing non-interactive --jira callers will start changing issue status after a minor upgrade. The changeset and docs say so plainly, so this is a deliberate choice rather than an oversight.
Reviewed 5b7d5cd for baldurpan · claude-opus-5-5 · 20 files · $0.65
worktree branch --jira <KEY> --startnow moves the Jira issue to its in-progress status once the worktree exists, the Jira twin of the Linear (#112) and ClickUp (#131) start support.Phases landed (plan is the body of #125):
startJiraIssuein the Jira integration: moves only anew-category issue, picks the transition by target status category, refuses an ambiguous or absent target (175e1db).jira.autoStartpersonal key, validated, prompted and documented (76fc0af).--startwired for--jirainbranch, the "not supported for Jira issues yet" warning removed, docs and skill updated (e6a5372).Release note:
minor,.changeset/jira-start-on-branch.md. It says plainly that a non-interactive--jirarun now moves the issue by default. Merging lands the note and ships nothing to npm; that waits on the release pull request.Owner check, not a defect: #212 asks for one run against a real Jira Cloud site.
Closes #125