// Run the VS Code extension release workflow end-to-end. Use when publishing a release, running prerelease, verifying the release branch, polishing changelog for release, or installing release vsixes for verification.
Polish the automated CHANGELOG for a release branch. Removes GUS refs, categorizes under-the-cover changes, improves customer-facing descriptions. Use when preparing/reviewing the changelog on a release branch, or when user mentions changelog quality.
Find open GitHub issues whose linked GUS work item is closed AND whose issue number appears in CHANGELOG.md, then close them. Use when user invokes /shipped-issues or asks to clean up shipped issues.
Use file-based span/log export for AI consumption. Where it lives, how to enable/clear, record format for Node and Web. Use when enabling span file dump, debugging traces for AI, or configuring local observability.
writing, running, and debugging Playwright tests; creating and recreating scratch orgs (Dreamhouse, minimal, non-tracking); working with their output from github actions
Author and use Wireit scripts for npm. Use when working with Wireit configuration, npm scripts, build pipelines, or when the user mentions Wireit.
Public API exported by salesforcedx-vscode-core activate(). Use when modifying SalesforceVSCodeCoreApi, the api object in activate(), exports from core index.ts, services sub-object, or evaluating whether a change to core is breaking. Also use when someone asks "does anything use X" for a core export.
| name | release |
| description | Run the VS Code extension release workflow end-to-end. Use when publishing a release, running prerelease, verifying the release branch, polishing changelog for release, or installing release vsixes for verification. |
Full doc: contributing/publishing.md
Run from repo root via npx ts-node (no global ts-node):
npx ts-node .claude/skills/release/detect-state.ts — outputs JSON with currentRelease, version, priorRelease, tagExists, onReleaseBranch, commitCount, branchUrl, compareUrlRun detect-state.ts first to capture all context for subsequent steps.
Check that the scheduled createReleaseBranch.yml ran:
gh run list --workflow=createReleaseBranch.yml -L 5 --repo forcedotcom/salesforcedx-vscode
Report status + timestamp. If the top-level run shows failure, inspect jobs — the workflow has two: Create Branch then Trigger Generate Changelog Workflow:
gh run view <runId> --repo forcedotcom/salesforcedx-vscode
Decision matrix:
Create Branch failed → branch never created. Re-run with default (minor):
gh workflow run createReleaseBranch.yml -f releaseType=minor --repo forcedotcom/salesforcedx-vscode
Create Branch succeeded but Generate Changelog failed → partial state: branch exists on remote but CHANGELOG is not updated for the new version. Recovery: delete the broken branch, then re-dispatch the workflow. Confirm no open PRs first.
gh pr list --state open --head release/v<version> --repo forcedotcom/salesforcedx-vscode
git push origin --delete release/v<version>
gh workflow run createReleaseBranch.yml -f releaseType=minor --repo forcedotcom/salesforcedx-vscode
gh workflow run createReleaseBranch.yml -f releaseType=patch --repo forcedotcom/salesforcedx-vscode
After any re-dispatch, watch the new run until it completes before Step 1:
gh run list --workflow=createReleaseBranch.yml -L 1 --json databaseId --repo forcedotcom/salesforcedx-vscode
gh run watch <databaseId> --repo forcedotcom/salesforcedx-vscode
Print branchUrl from detect-state.ts.
Print compareUrl and commitCount from detect-state.ts so user can review what's in this release without leaving the chat.
Check out the release branch:
git fetch origin && git checkout <currentRelease> && git pull
Read and follow .claude/skills/changelog/SKILL.md to polish packages/salesforcedx-vscode/CHANGELOG.md.
Verify the release date. The auto-generated header uses today + 2 days (see scripts/change-log-generator-utils.js getReleaseDate). This assumes a Monday branch-cut → Wednesday release. Releases always ship on Wednesday, even for re-runs or patches. If the header date is not the upcoming Wednesday, fix it and confirm the target date with the user before committing.
Show git diff packages/salesforcedx-vscode/CHANGELOG.md to user.
Wait for explicit "approved" before proceeding.
After approval:
git add packages/salesforcedx-vscode/CHANGELOG.md && git commit -m 'chore: polish changelog' && git push
After pushing, print a link to the rendered CHANGELOG on the branch so the user can share it with the team. Format:
https://github.com/forcedotcom/salesforcedx-vscode/blob/<currentRelease>/packages/salesforcedx-vscode/CHANGELOG.md
Stop here. Tell the user: "Let me know when the team has approved the changelog and you're ready to run PreRelease."
Do not proceed until user says so.
Dispatch when user signals approval:
gh workflow run prerelease.yml \
-f releaseBranch=<currentRelease> \
--ref develop \
--repo forcedotcom/salesforcedx-vscode
Capture the run:
gh run list --workflow=prerelease.yml -L 1 --json databaseId,status,url --repo forcedotcom/salesforcedx-vscode
Monitor until complete:
gh run watch <databaseId> --repo forcedotcom/salesforcedx-vscode
After PreRelease succeeds, the merge into main triggers testBuildAndRelease.yml. Monitor it:
gh run list --workflow=testBuildAndRelease.yml -L 1 --json databaseId --repo forcedotcom/salesforcedx-vscode
gh run watch <databaseId> --repo forcedotcom/salesforcedx-vscode
Confirm the release tag was created:
gh release view v<version> --repo forcedotcom/salesforcedx-vscode
Ask user: code or code-insiders? (default code)
gh release download v<version> \
--dir ~/Downloads/v<version> \
--pattern '*.vsix' \
--repo forcedotcom/salesforcedx-vscode
find ~/Downloads/v<version> -type f -name "*.vsix" -exec <binary> --install-extension {} \;
User should reload VS Code and run a few commands to validate.
Quip cannot be accessed programmatically from this skill, so the user must create the document. Tell the user:
Create a new Quip testing document from the team's release-testing template and name it Release Testing v<version> (e.g.
Release Testing v66.13.0), where<version>matches the GH release tag.
Use the version captured from gh release view v<version> in Step 7 (or detect-state.ts version field) so the title matches the published tag exactly. Wait for the user to confirm the doc is created and shared with the team before continuing.
Tell the user: "Let me know when you've finished manually testing the installed vsixes (logged in the Quip doc) and you're ready to publish to the Microsoft Marketplace and Open VSX."
Suggested smoke checks the user may run before confirming:
Do not proceed until the user explicitly confirms testing is complete.
After the GitHub Release is created in Step 7, publishVSCode.yml (Microsoft Marketplace) and publishOpenVSX.yml (Open VSX) auto-trigger on the release: [released] event. Both are gated by the publish GitHub Environment and wait for manual approval.
Once the user confirms readiness in Step 9, list the pending runs:
gh run list --workflow=publishVSCode.yml -L 1 --json databaseId,status,url --repo forcedotcom/salesforcedx-vscode
gh run list --workflow=publishOpenVSX.yml -L 1 --json databaseId,status,url --repo forcedotcom/salesforcedx-vscode
Print both run URLs and tell the user to approve each pending deployment in the GitHub UI (Actions → run → Review pending deployments → Approve and deploy). Approval cannot be performed by the same identity that triggered the run, so the user must do this themselves.
After approval, monitor each run to completion:
gh run watch <databaseId> --repo forcedotcom/salesforcedx-vscode
Verify the extensions are live before continuing:
Compose the post from packages/salesforcedx-vscode/CHANGELOG.md (top section). Format:
*Salesforce Extensions for VS Code v<version> is out* :tada:<https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode|VS Code Marketplace> — note "see the Changelog tab for full details"*Added* / *Fixed* (from ## Added / ## Fixed)#### foo) → blockquote (> foo) ([PR #N](url), [ISSUE #N](url)) trailersShow the composed post to the user in a fenced code block.
If Slack MCP is available: offer to post or draft to #platform-dev-tools. Wait for explicit approval or change feedback before calling slack_send_message / slack_send_message_draft.
If not: user copy-pastes manually.
gh commands include --repo forcedotcom/salesforcedx-vscodeprerelease.yml without explicit user signal