Shipped Issues

Cross-reference open GitHub issues against closed GUS work items and the shipped CHANGELOG to identify issues that were fixed and released, but never closed on GitHub.

Inputs

• Repo: forcedotcom/salesforcedx-vscode
• Changelog: root CHANGELOG.md on develop (full shipped history; each stable section folds every pre-release it contains). Not packages/salesforcedx-vscode/CHANGELOG.md — that holds only the latest pre-release delta.
• GUS alias: gus (see .claude/skills/gus-cli/SKILL.md)

Workflow

1. Get current CHANGELOG from develop

git fetch origin develop
git show origin/develop:CHANGELOG.md > /tmp/shipped-changelog.md

Do not switch branches; run from wherever the user is.

2. List open issues with W- references

gh issue list --repo forcedotcom/salesforcedx-vscode --state open --limit 500 --search "W in:body" --json number,title,body,url > /tmp/shipped-issues.json

The W in:body filter narrows to issues that contain the letter W — overly broad but cheap. Locally extract W-\d{6,9} matches per issue (regex; multiple W- per issue is allowed). Drop issues with no match.

3. Query GUS for status of each W-

Batch in chunks of ~50 W- names per query to stay under SOQL limits:

sf data query --query "SELECT Id, Name, Status__c, Last_Modified_Internal_Closed_Date__c FROM ADM_Work__c WHERE Name IN ('W-1234567','W-2345678', ...)" -o gus --json

Closed terminal statuses (any of these counts as closed): see .claude/skills/gus-cli/SKILL.md § Status__c values "Closed (terminal)".

Quick check: Status__c LIKE 'Closed%' OR Status__c IN ('Completed','Fixed').

4. Filter to candidates

Keep an issue only when every W- on the issue resolves to a Closed/Completed status in GUS. If any linked W- is still open, skip the issue (work isn't all done).

5. Cross-reference CHANGELOG

For each candidate issue number N, search /tmp/shipped-changelog.md for any of:

• ISSUE #N (case-insensitive)
• issues/N (link form)
• #N only when the surrounding line clearly references an issue, not a PR

If matched → issue is shipped. Record the matched CHANGELOG line for the closing comment.

6. Present the report

Show a table to the user before closing anything:

Also list any near-miss rows separately so the user can review:

• Issues where WIs are all closed but the issue # isn't in the CHANGELOG (maybe under-the-hood / not customer-facing)
• Issues where some W- are still open

7. Close issues — only after explicit user confirmation

For each confirmed issue, post a comment then close:

gh issue close <number> --repo forcedotcom/salesforcedx-vscode --comment "Closing — shipped in <version>. See CHANGELOG entry: <verbatim line>. (Linked work item <W-XXXXXXXX> is closed.)"

Do not loop-close without user confirmation. If many issues, present the full list and ask "Close all N?" once.

Edge cases

• Multiple W- per issue, mixed status: skip until all W- close.
• Issue body mentions W- in a quoted error or unrelated context: rare; surface as candidate anyway, the user reviews the table.
• CHANGELOG hit on a ## Under the Hood line: still counts as shipped — user can opt out per-row.
• Issue # shows up in CHANGELOG as [PR #N]: not a match. Only ISSUE #N / issues/N indicate the issue itself.
• No CHANGELOG match but WI closed long ago: list as near-miss, don't auto-close.

Output format

End with a one-line summary: Closed N issues; M near-misses for review.