release

name

release

description

Use when: creating a release, publishing a version, cutting a release, tagging a release, releasing plugin, release workflow, prepare release, create git tag, create GitHub release, update version, bump version, and update changelog. Covers: changelog extraction/review, semantic version validation, version bumping in VS Code + Rider manifests, guarded git commit/tag flow, and release status messaging.

Release Skill

Use this skill whenever the user asks to cut a release, tag a version, publish plugins, or create a GitHub release for QueryLens.

Release Workflow

Step 1 — Verify git working tree is clean

Run:

git status --short

If any modified, staged, or untracked files are listed, stop immediately and tell the user:

Working tree is not clean. Please commit or stash all changes before releasing.

Step 2 — Read the current changelog

Read CHANGELOG.md from the repo root. Extract everything under the ## [Unreleased] heading and stop at the next ## [ heading. Display that section to the user so they can review what is going into the release.

If the section is empty, ask:

The [Unreleased] section is empty. Are you sure you want to release with no recorded changes? (yes/no)

If the user answers no, stop.

Step 3 — Confirm the release version

If a version is supplied by the caller, use it. Otherwise ask for one (for example 0.0.3).

Validate that it matches MAJOR.MINOR.PATCH (three numeric segments separated by dots). If invalid, ask again until valid. Store it as VERSION.

Step 4 — Check the version does not already exist

Run:

git tag --list "v$VERSION"

If output is non-empty, stop and tell the user:

Tag v$VERSION already exists. Choose a different version.

Step 5 — Update CHANGELOG.md

Edit CHANGELOG.md at repo root:

1. Replace the ## [Unreleased] line with:

   ## [Unreleased]
   
   ## [VERSION] - YYYY-MM-DD
   

   where YYYY-MM-DD is today's ISO date.

2. Keep the previously unreleased content under the new [VERSION] heading.

3. Leave the new [Unreleased] section intentionally empty as the next-cycle placeholder.

Step 6 — Bump version references

Update exactly these files:

• src/Plugins/ef-querylens-vscode/package.json set "version" to VERSION
• src/Plugins/ef-querylens-rider/gradle.properties set pluginVersion to VERSION

Step 7 — Commit the version bump

Stage exactly these files and commit:

git add CHANGELOG.md \
	src/Plugins/ef-querylens-vscode/package.json \
	src/Plugins/ef-querylens-rider/gradle.properties
git commit -m "chore: release v$VERSION"

Do not add any other files.

Step 8 — Create and push the tag

Run:

git tag v$VERSION
git push origin HEAD
git push origin v$VERSION

The tag push triggers the GitHub Actions release workflow, which:

• Builds 6 platform-specific VS Code VSIXes and publishes them to the VS Code Marketplace
• Builds the Rider plugin ZIP (with daemon binaries for all 6 RIDs) and publishes it to JetBrains Marketplace
• Creates a GitHub Release with all artifacts attached

Step 9 — Confirm success

Tell the user:

✅ Released v$VERSION

• Commit pushed to origin
• Tag v$VERSION pushed — CI is now building and publishing all three plugins
• Check https://github.com/querylenshq/ef-querylens for pipeline status

Notes

• This skill is intentionally aligned with .claude/commands/release.md.
• If release workflow changes, update both files in the same commit.