twg-jira-resolve-merged-work

twg help

twg help describe <path>

CLI launcher fallback

twg <command>

command not found

$HOME/.local/bin/twg

$env:LOCALAPPDATA\Programs\twg\bin\twg.exe

Scope

• One Jira workitem key/URL.
• A small explicit list of Jira workitem keys/URLs.
• Board or sprint ID/URL.
• Epic key.
• Jira space/project key.

Workflow

1. Load Jira candidates.
   • Single/list: hydrate each provided workitem directly.
   • Sprint:

     jira sprint workitems query

     .
   • Board: board/backlog/sprint commands advertised by live help.
   • Epic or space: JQL-backed

     jira workitem query

     .
   • Hydrate key, title, status/category, assignee, updated time, parent, subtasks/blockers, and URL.
2. Split the set.
   • Candidates are not done/resolved. Peers are done in the same board, sprint, epic, or space.
   • Exclude epics/parents. Skip unresolved blockers or incomplete subtasks unless the user explicitly allows them.
3. Discover shared repo context set-wise.
   • Even for one item or a short list, infer context for the set together.
   • Extract repos/workspaces from linked PRs, commits, branches, project links, Compass/components, context queries, and resolved peers.
   • Use completed peers to infer common repos, assignees, Jira-key title/branch conventions, PR links, and merge-to-transition lag.
4. Check optional discovery signals.
   • If

     rovo list-apps

     shows Bitbucket or GitHub connected, use Rovo search for keys, titles, PR URLs, branches, and repos. Treat it as discovery until hydrated through TWG/provider/Jira evidence.
   • If

     search-code

     is available, search exact keys first, then distinctive title terms in discovered repos. Strong hits are branch names, commit text, changed files, or symbols; broad fuzzy hits stay weak.
5. Expand likely implementers.
   • Prefer assignees from completed peer items and candidates. Treat reporters and commenters as weak hints.
   • Query merged PRs authored by these assignees in the window, scoped by discovered repos first; if unknown, infer repos from author/date results.
6. Search merged PRs in batches.
   • Prefer one merged-PR query per repo/window, then match locally across all candidate keys. One PR may satisfy multiple exact keys.
   • Match exact keys in PR title, description, branch, commits, and linked issue metadata.
   • Fall back to per-workitem lookup only for no evidence, priority items, or ambiguity.
7. Score confidence.
   • High: exact key in merged PR or linked PR metadata, plausible timing, no open same-key PR, no blockers/subtasks, and target transition exists.
   • Medium: same assignee/repo with strong title similarity, or exact key only in commit/search-code evidence.
   • Low: fuzzy similarity, same author only, unknown repo, or ambiguity.
8. Produce the dry-run plan.
   • Table columns: workitem key/title, current status, proposed transition, confidence, brief rationale, PR title/URL, merge date, last Jira update, link/repo proposal, PR title-fix proposal, skipped reason, and verification.
   • Include exact commands only after live-help verification. Never present low-confidence rows as executable.

Mutations

• Transition: list transitions first, then use only the approved done/resolved target.
• Link enrichment: if links are missing, offer

  jira workitem link weblink

  for PR/repo URLs after querying links and verifying help. Do not claim this creates native development-panel links.
• PR title fix: for Bitbucket, update title only when a verified

  bitbucket pull-requests get

  leaf can read the PR, write access is verified, the PR is confidently tied to the item, and the user approved it. For GitHub, update only when an authenticated write tool is available and access is verified; otherwise skip with the reason.
• Verification: re-read each changed workitem and PR. Report changed keys, statuses, URLs, and failed rows.

Output

• executable high-confidence rows,
• review-needed medium-confidence rows,
• skipped unsafe rows,
• missing repo/auth/permission coverage.