Menu
Manage the full software release process, including version bumps, changelogs, Git tags, and GitHub releases.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Audit and update all project documentation to stay in sync with the current development status.
Perform a project-wide code review covering security, correctness, code quality, tests, documentation, and style.
Stage, commit, and push changes to the remote repository with a well-formed commit message.
Perform project-wide security audits of the bypass password manager.
| name | release-engineering |
| description | Manage the full software release process, including version bumps, changelogs, Git tags, and GitHub releases. |
When performing release engineering for bypass, always follow these steps:
Verify the build is clean — run the full check suite from a clean state:
cargo clean
cargo build --release
cargo test
cargo clippy --all-targets -- -D warnings
cargo fmt --check
All must pass before proceeding. A release that ships with warnings or formatting drift is a process failure.
Run the security audit — apply the security-audit skill. A password manager release must not ship with any Critical or High finding open. cargo audit must report zero unpatched advisories in the dependency tree.
Determine the release type — review all unreleased commits since the last tag and classify the release as major, minor, or patch following Semantic Versioning. Until 1.0.0, breaking changes may land in minor bumps, but they must still be called out in the changelog. 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 build once to refresh 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. Highlight any change that affects on-disk store layout or pass-compatibility — users may need migration steps.
Reconcile doc/ROADMAP.md — confirm that every milestone whose work is included in this release has its checkboxes ticked. If a phase is fully complete, note it (e.g., add *(complete in vX.Y.Z)* next to the phase heading).
Commit the release — stage Cargo.toml, Cargo.lock, CHANGELOG.md, and doc/ROADMAP.md together and commit with the message chore: release vX.Y.Z.
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. Note: use --notes (not --body) for the release description. Attach prebuilt binaries if release-time packaging is configured.