// Manage the full software release process, including version bumps, changelogs, Git tags, and GitHub releases.
Perform a structured code review of staged or recently changed Warpine source files, covering correctness, security, test coverage, clean-room compliance, and documentation hygiene.
Audit and update all project documentation to stay in sync with the current development status.
Stage, commit, and push changes to the remote repository with a well-formed commit message.
Perform project-wide security audits focused on KVM hypervisor escape, guest memory safety, and dependency vulnerabilities.
| name | release-engineering |
| description | Manage the full software release process, including version bumps, changelogs, Git tags, and GitHub releases. |
When performing release engineering, always follow these steps:
Verify the build is clean — run cargo clean && cargo build 2>&1 to confirm a from-scratch build passes with no errors or unexpected warnings. Then run cargo test 2>&1 to confirm all tests pass. Then run cargo clippy -- -D warnings 2>&1 to confirm there are zero lint warnings. Do not proceed if any of these steps fail.
Determine the release type — review all unreleased commits since the last tag (git log $(git describe --tags --abbrev=0)..HEAD --oneline) and classify the release as major, minor, or patch following Semantic Versioning. Present the recommendation to the user and confirm before proceeding.
Update the version — bump the version field in Cargo.toml to match the new release version. Run cargo check to regenerate Cargo.lock.
Update CHANGELOG.md — add a new version entry at the top following the Keep a Changelog format. Group changes under Added, Changed, Fixed, Removed, or Security as appropriate. Include all notable changes since the previous release.
Commit the release — stage Cargo.toml, Cargo.lock, and CHANGELOG.md together and commit with the message chore: release vX.Y.Z (plus co-author trailer per the commit-and-push skill).
Tag the release — create an annotated Git tag (git tag -a vX.Y.Z -m "vX.Y.Z") and push both the commit and the tag to the remote (git push && git push --tags).
Create a GitHub release — use gh release create vX.Y.Z --title "vX.Y.Z" --notes "..." with the corresponding CHANGELOG.md section as the release notes. Use --notes (not --body) for the release description.
