release

Release codex-buddy

Publish the next codex-buddy version through the repository's existing cargo-dist and tray-app workflows. Treat the release as complete only after both workflows and all expected assets are verified.

Guardrails

• Use this skill from the beginning of every codex-buddy release, including release retries and verification-only requests.
• Work only in the CodePrometheus/codex-buddy checkout. Verify the repository and read CLAUDE.md before acting.
• Treat an unqualified release request as authorization to commit the intended current changes, push main, and push the selected version tag. Do not include unrelated changes.
• Never rewrite published history, move an existing tag, delete a tag or release, or rerun or manually dispatch a failed workflow without explicit user approval.
• Report partial state truthfully. A pushed tag is not a completed release.
• Never print credentials or token values.

1. Inspect state

Run read-only checks first:

git remote -v
git status --short --branch
git diff
git fetch origin --tags --prune
git log --oneline --decorate -n 12
git tag --sort=-version:refname | head -n 10
gh auth status
gh release list --limit 10

Require:

• branch main;
• no unreviewed or unrelated local changes;
• local main not behind origin/main;
• authenticated GitHub access;
• the target version absent locally and remotely.

For a small compatible fix, select the next patch after the highest stable vX.Y.Z tag. Ask before choosing a minor, major, or prerelease version when intent is ambiguous.

2. Prepare the release

Keep implementation and version commits separate when there are uncommitted product changes:

1. Stage only the exact intended files and create a conventional fix:, feat:, docs:, or chore: commit.
2. Update only [workspace.package].version in Cargo.toml.
3. Do not add Cargo.lock; this repository intentionally ignores it.
4. Commit the version change as chore: bump version to X.Y.Z.