/list-open-work

Answer one question: what of mine is open in this repo, and which ticket does each carry? Lead with the list. Anything else goes after it, in prose.

This repo only

Scope is the git checkout you are in (worktree or primary). Read its origin. List my open MRs/PRs against that remote. Stop there.

• Not a git repo → say so and stop. Do not hunt another project.
• Do not list another origin, org, forge, or tracker from memory, another session, or another worktree.
• Infer the ticket key from this repo's branches/titles (e.g. PROJ-123 in feat/PROJ-123-slug). Never reuse a prefix you saw somewhere else.

git rev-parse --show-toplevel
git remote get-url origin

Output format

Write it straight into the chat as ordinary rendered markdown. Never wrap it in a code fence — the links have to be clickable.

Blank line between every item. Markdown treats a single newline as a space, so adjacent lines become one paragraph. That is a failure. Each MR is its own paragraph: newline, blank line, next line.

Exactly this shape. Header is Open MRs: or Open PRs:. No bullets, no emoji. The number and the ticket key are both links. Ticket sits in trailing [KEY].

Open MRs:

!42 - shorten the save path [PROJ-101]

!41 - default the new flag on [PROJ-99]

!30 - expose status history on the public API

• Descending by number. !N on GitLab, #N on GitHub. "MRs" vs "PRs" likewise.
• One paragraph each: <!|#><N> - <title> [<KEY>]. No bold.
• Ticket in trailing [KEY]. Move it there if the author buried it mid-title: perf: PROJ-77 — cut over-fetch becomes perf: cut over-fetch [PROJ-77].
• No ticket → omit the [KEY]. Don't invent one, don't write (no ticket).
• Keep the MR/PR title as-is (minus the relocated key). Don't rewrite it.

Wrong (renders as one wrapped line):

Open MRs:
!42 - shorten the save path [PROJ-101]
!41 - default the new flag on [PROJ-99]

Pasting into Slack is a separate ask. Forge/tracker integrations linkify !42 and PROJ-101 on their own, so that version is the same lines with the link syntax stripped — still one item per line.

Collect

Mine means authored by me. Resolve my username from the API — never guess it.

GitLab origin:

glab api user
glab api "projects/<url-encoded-path>/merge_requests?state=opened&scope=all&per_page=100"

Filter to author = me. <url-encoded-path> is this origin's path, not a path from another repo.

GitHub origin: gh pr list --author @me --state open --json number,title,headRefName,body

Ticket = first \b[A-Z][A-Z0-9]+-\d+\b in the title, then the branch, then the description. Use that key's tracker host as this repo uses it — don't guess a site from another company.

Jira account verification

Validate actual Jira results against the repository's tracker project; acli jira auth status alone can report the intended site while searches still reach another account. If project keys or API hosts contradict the expected workspace, explicitly select the saved account with acli jira auth switch --site <repo-tracker-host> --email <verified-email>, then read back a known ticket before trusting the list. Do not reuse results from the wrong site.

Use acli jira workitem search --paginate and compare the distinct fetched count against the same JQL with --count. Search has a restricted field list; retrieve timestamps, descriptions, and comments with workitem view --fields summary,description,status,priority,assignee,updated,comment,issuelinks --json instead. Read comments before classifying Testing tickets as new implementation work.

Then, in prose

Only the things that change what I'd do next:

• Conflicts with the default branch — blocked, not in review. GitLab recomputes mergeability lazily, so a plain MR GET happily returns a stale has_conflicts: false. Force it and read merge_status:

glab api "projects/<path>/merge_requests/<iid>?include_diverged_commits_count=true"
# cannot_be_merged + has_conflicts → needs a rebase; diverged_commits_count = how far behind

• Red pipelines (head_pipeline.status).
• Ticket status that contradicts the MR: green with every thread resolved but the ticket still says In Progress.
• No ticket plus months of age — give the age, offer to close.

Skip approvals unless asked. Don't narrate fields that changed nothing.

For GitHub readiness checks, read submitted review bodies and human PR comments as well as paginated inline threads. A COMMENTED review can contain explicit merge blockers even when unresolved inline-thread count is zero and CI is green. Match each review to its reviewed head; older findings need rechecking rather than being asserted as current defects.

Keep CI conclusions, conflict status, and substantive review blockers separate. Query gh pr checks for each current head; UNKNOWN mergeability is unverified, not conflict-free. Persist the inventory and aggregate counts programmatically before reporting totals.

When this repository uses GitHub issues rather than tracker keys, inspect explicit issue links in the PR body as well as closingIssuesReferences. An intentionally non-closing reference can be the real attached ticket. Read the issue's state and discussion before changing it; a partial fix or pending live verification can require keeping it open.