| name | release |
| description | Use when orchestrating an CertaMesh/gaze release end to end, especially when the user says cut release, ship vX.Y.Z, tag vX.Y.Z, publish vX.Y.Z, or release vX.Y.Z. Covers pre-flight gates, explicit tag authorization, GitHub and crates.io workflow expectations, post-tag verification, escalation rules, and the counter-pattern to avoid: do not just push a tag and hope. |
Release Orchestration
Use this skill for Gaze release execution. It complements the release-notes
skill, which controls release-note voice only.
Do not cut a release, push a tag, or trigger publish workflows until the
pre-flight checklist is green and the user gives an explicit lock signal such
as "Do it yourself", "Tag + push", or an equivalent direct instruction.
Pre-Flight Gates
Run from main after all release-blocker PRs are merged.
- Confirm the working tree is clean and
main is at the intended merge commit.
- Confirm all open PRs marked as
v0.X.0-final blockers are merged.
- Confirm the workspace version pin matches the about-to-tag version in the
root
Cargo.toml and all per-crate Cargo.toml files.
- Run
cargo run -p xtask -- ci-feature-matrix and require green.
- Run
cargo run -p xtask -- readme-version-check and require green.
- Run
git grep -E '/Users/[a-z]+' and require zero tracked-file matches.
Path-leak output is release-blocking until scrubbed to ~/ or $HOME.
- Dogfood Gaze on its own release text: pipe the modified
CHANGELOG.md
section, plus any optional extra release text passed to the release
preflight, through gaze clean and verify zero detections. GitHub Release
bodies use generated notes; dist/release-notes/ is not committed. This
preserves the feedback-dogfood-gaze-on-own-output memory.
- Verify benchmark claims in the changelog or release PR body link to the
script and hardware specification that produced them. This preserves the
feedback-bench-claims-reproducible memory.
If any step fails, stop and fix the release branch. Do not tag around a red
checklist.
Tag Procedure
Only after explicit user lock signal:
git tag -a vX.Y.Z -m "vX.Y.Z" <merge-sha>
git push origin vX.Y.Z
Use an annotated tag on the merge commit. Do not tag a local-only commit, an
unmerged branch head, or a dirty working tree.
The tag push auto-fires two workflows:
release.yml: builds binaries and creates the GitHub Release.publish-crates.yml: publishes the 11 crates via OIDC trusted publishing.
Do not publish to crates.io manually. The workflow owns publication order and
idempotent retries.
Post-Tag Verification
After the workflows finish:
- Confirm
gh release view vX.Y.Z returns the release.
- Confirm both workflow runs succeeded:
release.yml and publish-crates.yml.
- Confirm all 11 crates are published by checking
https://crates.io/api/v1/crates/<name> and expecting
max_version == X.Y.Z for:
gaze-types, gaze-audit, gaze-recognizers, gaze-pii,
gaze-assembly, gaze-mcp-core, gaze-mcp-rmcp, gaze-mcp-bridge,
gaze-document, gaze-proxy, and gaze-cli.
- Update the orchestrator scratchpad with released URLs:
GitHub Release URL plus the 11 crates.io URLs.
Escalation Rules
- Do not push tags without an explicit user lock signal.
- Do not publish to crates.io manually.
- Do not amend, delete, or force-push a tag after it has been pushed. If a
released tag is wrong, make a new patch release.
- Do not put local absolute paths in release notes, PR bodies, or commit
messages. Use
~/ or $HOME.
- If generated GitHub release notes need prose changes after publication, edit
the GitHub Release body explicitly and keep
CHANGELOG.md as the curated
source.
Counter-Pattern
Do not just push a tag and hope. A Gaze release is complete only when the
pre-flight gates are green, the tag was explicitly authorized, both workflows
succeeded, all 11 crates report the expected version, and the orchestrator
scratchpad records the shipped URLs.
