Release Candidate Preparation

Release Candidate Preparation

Use this skill only when the user explicitly invokes $release-candidate-prep and supplies a release version without a leading v, for example VERSION=0.20.1. This skill is the manual fallback for the GitHub Actions release workflow. Ordinary bot releases use .github/workflows/release-candidate.yml; do not invoke this local worktree procedure inside Actions.

For normal Release Please releases, use $final-release-review <release PR URL> instead. Do not create a manual candidate to review or finish the bot PR.

Non-negotiable boundaries

• Treat explicit invocation as authorization to fetch origin/main, create one dedicated detached release worktree, run branch-free release-readiness gates there, create or replace the local release/v<version> in that worktree only after those gates pass, update the five release-owned files, and create one local commit. If the branch already exists locally or remotely, the required final local state is still exact current origin/main plus only the new release commit; an existing local branch may be replaced only when it is not checked out in another worktree.
• Keep the user's source checkout on its existing clean main commit. Do not fast-forward it, switch its branch, or materialize release files there. Leave the dedicated release worktree in place for green handoff, blocked review, or recoverable failure.
• Never push, open or edit a pull request, add labels or milestones, create a release, or otherwise mutate GitHub. Never run gh.
• Own exactly pyproject.toml, uv.lock, .release-please-manifest.json, src/agents/version.py, and tests/fixtures/released_api_contract.json. Runtime, documentation, workflow, or other repository changes must land on main before release preparation.
• Do not stash, delete, overwrite or remove an existing worktree, or work around unrelated local changes. Fail before branch creation when the initial checkout is dirty or is not on main, the dedicated worktree is not clean and detached at refreshed origin/main, an existing local release branch is checked out in another worktree, the prospective packaged-contract gate fails after the allowed dependency-bootstrap recovery, the planning review blocks, or origin/main advances after those gates run.
• Treat $final-release-review as the controlling release checker, not only as a report generator. Its planning gate must be green before branch creation, and its final-candidate gate must inspect the materialized worktree and be green before PR-ready handoff. Any candidate content, commit, or base change invalidates the previous green result.
• Remove inherited OPENAI_API_KEY from every child command. Release preparation does not require a live OpenAI API request.
• Stop after the local commit, final release review, and copy-ready handoff. The user owns the push and pull-request creation.

1. Establish the release input

Require one semver-like version without a leading v. Do not infer a version from milestones, branch names, or local modifications. Announce that the skill will create and retain a dedicated release worktree with one local commit, keep the source checkout unchanged, and not write to GitHub.

Read $final-release-review completely before starting. Its final-candidate report is the release pull request description. Do not use $pr-draft-summary for the release candidate itself; this skill owns the fixed release branch, commit subject, title, and description. Continue to use $pr-draft-summary normally when implementing changes to this skill or other repository behavior.

2. Create an isolated branch-free preflight input

From the repository root, run:

env -u OPENAI_API_KEY -u GITHUB_TOKEN -u GH_TOKEN UV_DEFAULT_INDEX=https://pypi.org/simple uv run --frozen python .agents/skills/release-candidate-prep/scripts/prepare.py preflight --version <version> --worktree-root <codex-worktree-root>

The helper must complete all of these operations or fail with an actionable error while leaving the source checkout on its original main commit:

1. Verify the repository root, main branch, and clean working tree.
2. Inspect whether release/v<version> exists locally or remotely. Permit replacement, but fail if the local branch is checked out in another worktree.
3. Fetch main into origin/main without merging or switching the source checkout.
4. Choose a unique task-oriented path under the configured Codex worktree root. Check both the filesystem and git worktree list; never reuse or delete a collision.
5. Create a detached worktree at exact refreshed origin/main, then require that worktree to be clean, detached, and at the exact 40-character base commit.
6. Recheck that an existing local release branch remains replaceable and require the source checkout to remain clean on main at its original commit.