| name | release |
| description | Release a new version of the DevoxxGenie IntelliJ plugin — prompt for the target version, bump it in the build files, write a curated CHANGELOG.md entry and plugin.xml change-notes from the git/PR history since the last tag, build to verify, then commit, tag, and publish a matching GitHub release. Use this whenever the user wants to cut, ship, publish, or tag a new plugin release, bump the version for a release, or asks to "release vX.Y.Z" / "do a release" / "make a new version". |
Release a new DevoxxGenie plugin version
This skill cuts a complete plugin release: version bump → curated changelog → plugin
change-notes → build → commit → tag → GitHub release. The goal is a release whose
CHANGELOG.md, plugin.xml change-notes, and GitHub release body all tell the same story,
written from the actual work done — not a raw dump of PR titles.
The release commit lands on the current default branch (master), matching how prior
releases were cut here. Do not create a feature branch for a release.
Step 1 — Ask for the target version
Never assume the next version. Show the current version and ask the user what to release.
grep -E '^version\s*=' build.gradle.kts | head -n1
Offer patch / minor / major as a guide (e.g. current 1.7.4 → patch 1.7.5, minor
1.8.0, major 2.0.0) but let the user state the exact number. Use it verbatim as
X.Y.Z (tags are vX.Y.Z).
Step 2 — Gather the history since the last release
Find the previous tag, then read what actually changed. You need the substance of each
change, so look at PR titles and bodies/commits, not just subject lines.
git describe --tags --abbrev=0
git <prev-tag>..HEAD --oneline
gh list --state merged --base master -- 30 \
--json number,title,author,mergedAt,body
