القائمة
Cut the first RC pre-release directly from develop. Use when the user says "pre-release", "prerelease", "cut an RC", or "start a release".
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Trigger a CI release for virgil-crypto-c. Runs the unified release.yml workflow_dispatch that builds Go static libs and Apple xcframeworks in CI, bumps the version, commits binaries, and creates both version tags. Use when the user says "release", "tag", or "cut a release".
Bump the project version across all language wrappers (Python, Java, PHP, Swift, Go, WASM, C headers). Use when the user says "bump version", "update version", or "set version".
استنادا إلى تصنيف SOC المهني
| name | pre-release |
| aliases | ["prerelease","pre release"] |
| description | Cut the first RC pre-release directly from develop. Use when the user says "pre-release", "prerelease", "cut an RC", or "start a release". |
| compatibility | Requires gh CLI authenticated to the VirgilSecurity/virgil-crypto-c repo. |
| allowed-tools | Bash Read |
Trigger the first release candidate (MAJOR.MINOR.PATCH-rc.1) directly from develop via the unified release.yml workflow. No release branch is created — develop is the release branch.
Use this skill when you are ready to cut the first RC for a version. Subsequent RCs and the final production release all run from develop via /release.
develop is in the expected state (CI green, no stale WIP commits)ChangeLog.md and README.md do not need entries yet — required only before the final production releaseIf the user provided a version argument, parse it. Acceptable forms: 0.19.0, v0.19.0, 19.0, 0.19. Normalize to bare MAJOR.MINOR.PATCH — no leading v, no label suffix. If not provided, ask:
"What version are you releasing? (e.g.
0.19.0)"
The first RC label will be appended automatically: MAJOR.MINOR.PATCH-rc.1.
Show the user what will happen and ask for confirmation before proceeding:
Release: X.Y.Z-rc.1 (from develop, via release.yml workflow)
Tags: wrappers/go/vX.Y.Z-rc.1 and vX.Y.Z-rc.1
gh workflow run release.yml \
--field version=X.Y.Z-rc.1 \
--field branch=develop
# Wait a moment for the run to appear, then get its ID
gh run list --workflow release.yml --limit 1
# Watch it to completion
gh run watch <run-id>
git fetch --tags
git tag | grep "X.Y.Z-rc.1"
Both tags should be present:
vX.Y.Z-rc.1wrappers/go/vX.Y.Z-rc.1| Step | Action |
|---|---|
build-go (parallel) | Cross-compiles Go static libs for 5 platforms |
build-apple (parallel) | Builds Apple xcframeworks on macos-26 |
release-commit | Bumps version, assembles artifacts, runs swift build + swift test, commits to develop, pushes both tags |
| Workflow | Action |
|---|---|
release-python.yml | Wheels to TestPyPI (pre-release label present) |
release-java.yml | Java/Android to Maven Central staging + GitHub Release |
release-php.yml | PHP packages to GitHub Release |
release-swift.yml | XCFrameworks to GitHub Release |
release-wasm.yml | WASM bundle to npm (with rc dist-tag) |
When fixes land on develop and a new RC is needed, use /release directly:
gh workflow run release.yml \
--field version=X.Y.Z-rc.2 \
--field branch=develop
Or just run /release and specify the version and branch when prompted.
When the RC is stable, run /release X.Y.Z (branch defaults to develop). Before doing so, ensure ChangeLog.md has an entry for X.Y.Z and README.md is current.
If the workflow pushed the release commit but failed to push the tags:
git fetch origin develop
SHA=$(git rev-parse origin/develop)
git tag "wrappers/go/vX.Y.Z-rc.1" "$SHA"
git push origin "refs/tags/wrappers/go/vX.Y.Z-rc.1"
git tag "vX.Y.Z-rc.1" -m "vX.Y.Z-rc.1" "$SHA"
git push origin "refs/tags/vX.Y.Z-rc.1"