chore: add a shared release skill and candidate verifier

.agents/skills/release/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: release
+description: Prepare, resume, or verify Apache Asyncband releases when release-manager work is requested, including candidate artifacts, votes, publication, and recovery.
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Release Apache Asyncband
+
+Help the release manager carry out the requested release work, explain the current state, and propose practical next steps. Keep release coordination in the main conversation. Delegate substantial candidate verification when it can run independently, and use the shared license-audit skill for the licensing review. The release manager and project community make release decisions.
+
+## Resume the requested work
+
+Establish the requested scope and what has already happened from the conversation, current checkout, and relevant external records. Read the affected parts of `asyncband/Cargo.toml`, `Cargo.lock`, `CHANGELOG.md`, `.github/workflows/release.yml`, `.asf.yaml`, and `xtask/src/main.rs` when needed. Use live GitHub, ASF distribution, mailing-list archives, and registry records to resolve uncertain state. Load only the reference for the current phase; an existing candidate does not require repeating preparation or setup.
+
+Carry forward the user's existing authorization. A status check, review, or plan stays read-only. For execution, complete authorized work and prepare any proposed external action before asking about authorization that is actually missing. Sending vote or announcement messages, publishing, merging, or changing tags needs authorization for that action; opening this skill does not provide it. Preserve the user's work when selecting a checkout or creating a release worktree.
+
+Keep these values and supporting links in the conversation so work can resume across turns:
+
+- `VERSION`: the final crate version, such as `0.7.2`; RCs do not change the package version.
+- `RC`: the positive candidate number; `RC_TAG` is `v${VERSION}-rc.${RC}`.
+- `RELEASE_COMMIT`: the merged release pull request commit bound to the candidate.
+- `RELEASE_DIR`: an absolute working directory outside the repository for artifacts, verification, and SVN checkouts; reuse it while continuing the same candidate.
+- Candidate tag and artifact location, checksum/signature results, relevant CI runs, PPMC/IPMC vote threads and results, and completed publication steps.
+
+Report completed work with evidence, the next useful step, and any input still needed. Distinguish pending, failed, and unverified steps. Keep handoff notes in the conversation unless the user requests a file.
+
+## Choose the current phase
+
+| Current work                                      | Read                                                 |
+| ------------------------------------------------- | ---------------------------------------------------- |
+| Version/changelog PR, RC, artifacts, or staging   | [Candidate preparation](references/candidate.md)     |
+| Checking an existing candidate's artifacts        | [Candidate verification](references/verification.md) |
+| Voting, approved publication, follow-up, or retry | [Publication](references/publication.md)             |
+
+The phase guides are the maintained release procedure for both people and agents. Existing infrastructure is described in [Infrastructure](references/infrastructure.md); read it only for configuration changes, a new release manager's signing key, or infrastructure troubleshooting.
+
+Links within this skill resolve from the containing document and stay within this skill's files. Repository paths such as `.github/workflows/release.yml` resolve from the caller's Asyncband repository root, which may differ from the current working directory. Locate the `license-audit` skill and configured agents by name; if skill discovery is unavailable, read `.agents/skills/license-audit/SKILL.md` from that repository root. Do not infer repository locations by walking upward from this skill's installation directory.
+
+Read `cargo x --help` and the relevant subcommand help before running repository checks.
+
+## Delegate candidate verification
+
+Use the `release_verifier` Codex agent for a substantial check of an existing candidate when the main agent can continue independent work, such as preparing vote materials. Other coding agents can delegate the same candidate-verification guide to a worker or follow it directly. Keep a small status query in the main conversation.
+
+Give the verifier the repository root, candidate commit and tag, version, absolute artifact paths, expected signing fingerprint and its provenance, requested checks, and a scratch directory outside the checkout. It returns the checked revision and artifacts, observed results, and remaining gaps. Preserve the original artifacts for a separate `license-audit` review; the verifier does not duplicate that audit. Collect the results before staging or publishing the candidate.
+
+## Candidate and publication continuity
+
+The signed source archive approved by the Apache Incubator PMC and published through ASF distribution is the official Apache release. Its name is `apache-asyncband-${VERSION}-incubating-src.tar.gz`. The crates.io package is a convenience distribution from the same approved commit; keep its Cargo-generated name and layout.
+
+Keep the RC tag, commit, artifacts, and vote tied together. A later `main` commit does not invalidate an existing candidate. Reuse an existing signed tag and staged bytes when retrying a transient failure. If candidate content changes or the community rejects it, agree on the replacement candidate and increment `RC`; preserve existing tags rather than rewriting them.
+
+After both vote results record approval, promote the exact voted source artifacts. The signed final `v${VERSION}` tag uses the approved RC commit and starts the crates.io publication workflow, subject to the configured `release` environment review. Successful CI alone does not establish vote approval. Confirm each external action's result before reporting completion or retrying it.
+
+Use the shared `license-audit` skill to examine the relevant checkout or artifact contents. In Codex, the configured `license_auditor` can perform a delegated review; another agent can follow the same skill directly. Provide the candidate revision and actual artifact paths, then discuss the review's evidence and suggestions with the release manager.
+
+Follow the current [ASF Release Policy](https://www.apache.org/legal/release-policy.html), [Release Distribution Policy](https://infra.apache.org/release-distribution), [Release Creation Process](https://infra.apache.org/release-publishing.html), and [Incubator release guidance](https://incubator.apache.org/guides/releasemanagement.html). Explain any relevant ambiguity with its source and practical options instead of treating incomplete evidence as a project defect.

.agents/skills/release/references/candidate.md

@@ -0,0 +1,112 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Prepare and stage a release candidate
+
+## Prepare the release pull request
+
+For a new release, start from current `main` and choose `VERSION` from the changes since the latest crates.io release. If the release pull request or candidate already exists, resume its recorded version and commit.
+
+1. Change `version` in `asyncband/Cargo.toml` and refresh `Cargo.lock` with Cargo.
+2. Move the entries under `Unreleased` in `CHANGELOG.md` into an undated `v${VERSION}` section immediately below it, then restore an empty `Unreleased` section. Keep user-impacting sections ordered as breaking changes, new features, bug fixes, and improvements; add the actual release date only after publication.
+3. Review `LICENSE`, `NOTICE`, `DISCLAIMER`, source headers, and bundled dependencies using the `license-audit` skill. Codex can delegate that review to `license_auditor`; provide the repository root and requested revision. Use its evidence and suggestions to decide what follow-up is needed during release preparation.
+4. Run the release checks:
+
+```shell
+cargo x lint
+cargo x check
+cargo x test --no-capture
+RUSTUP_TOOLCHAIN=1.86.0 cargo x test --no-capture
+cargo x semver --release-version "${VERSION}"
+cargo publish --package asyncband --locked --dry-run
+```
+
+For a semver-major release, including a pre-1.0 minor release such as `0.7.0`, the semver command uses minor compatibility rules to report breaking API changes. When it reports expected changes, record and review them in `CHANGELOG.md`, then rerun:
+
+```shell
+cargo x semver --release-version "${VERSION}" --acknowledge-breaking-changes
+```
+
+Merge the release pull request and record its merge commit as `RELEASE_COMMIT`. Every candidate artifact, the final tag, and the crates.io package use this exact commit.
+
+## Create and validate a release candidate
+
+For a new candidate, create a release directory outside the repository and a detached worktree at `RELEASE_COMMIT`. When resuming, reuse the recorded `RELEASE_DIR`, worktree, and RC tag. Run later Git and Cargo commands from that worktree root.
+
+```shell
+RELEASE_DIR="$(mktemp -d "${TMPDIR:-/tmp}/asyncband-release.XXXXXX")"
+RC_TAG="v${VERSION}-rc.${RC}"
+git fetch https://github.com/apache/asyncband.git main
+git worktree add --detach "${RELEASE_DIR}/checkout" "${RELEASE_COMMIT}"
+cd "${RELEASE_DIR}/checkout"
+git grep -F "version = \"${VERSION}\"" -- asyncband/Cargo.toml Cargo.lock
+git grep -Fx "## v${VERSION}" -- CHANGELOG.md
+test -z "$(git status --porcelain)"
+git tag --sign "${RC_TAG}" \
+  --message "Apache Asyncband ${VERSION} release candidate ${RC}" \
+  "${RELEASE_COMMIT}"
+git push https://github.com/apache/asyncband.git "${RC_TAG}"
+```
+
+Wait for the `Release` GitHub Actions workflow to pass. The workflow validates the RC tag and runs `cargo publish --dry-run` against the unchanged `${VERSION}` package; it skips the crates.io publish job for RC tags. A candidate that needs a code change gets a new release pull request, merge commit, RC number, and signed tag.
+
+## Build and verify the source archive
+
+For a new candidate, build the source archive from the verified RC tag. Reuse existing signed artifacts for a retry of the same candidate. The `incubating` marker is required in the filename, and `gzip -n` keeps the gzip header independent of the local build time.
+
+```shell
+RC_TAG="v${VERSION}-rc.${RC}"
+SOURCE_DIR="apache-asyncband-${VERSION}-incubating-src"
+ARTIFACT_DIR="${RELEASE_DIR}/dist"
+mkdir -p "${ARTIFACT_DIR}"
+git verify-tag "${RC_TAG}"
+git archive --format=tar --prefix="${SOURCE_DIR}/" "${RC_TAG}" \
+  | gzip -n -9 > "${ARTIFACT_DIR}/${SOURCE_DIR}.tar.gz"
+(
+  cd "${ARTIFACT_DIR}"
+  shasum -a 512 "${SOURCE_DIR}.tar.gz" > "${SOURCE_DIR}.tar.gz.sha512"
+  gpg --armor --detach-sign --local-user "${ASF_GPG_FINGERPRINT}" \
+    "${SOURCE_DIR}.tar.gz"
+)
+```
+
+Verify the existing artifacts with the [candidate-verification guide](verification.md), directly or through `release_verifier`. Supply the candidate identity, signing-key fingerprint, repository root, and absolute artifact paths. Keep the signed archive unchanged throughout verification.
+
+For the separate `license-audit` review, provide the original source archive, the extracted source, and the Cargo package produced by verification, together with `RELEASE_COMMIT`. Discuss its evidence and suggestions with the release manager. Keep the verification directory available until both reviews finish; then remove that disposable directory.
+
+## Stage the candidate on ASF infrastructure
+
+Check whether this candidate is already staged. For a new staging operation, check out a working copy under `RELEASE_DIR`, add the three candidate files, and commit them:
+
+```shell
+svn checkout --depth=empty \
+  https://dist.apache.org/repos/dist/dev/incubator/asyncband "${RELEASE_DIR}/svn-dev"
+mkdir "${RELEASE_DIR}/svn-dev/${VERSION}-rc.${RC}"
+cp \
+  "${ARTIFACT_DIR}/${SOURCE_DIR}.tar.gz" \
+  "${ARTIFACT_DIR}/${SOURCE_DIR}.tar.gz.asc" \
+  "${ARTIFACT_DIR}/${SOURCE_DIR}.tar.gz.sha512" \
+  "${RELEASE_DIR}/svn-dev/${VERSION}-rc.${RC}/"
+svn add "${RELEASE_DIR}/svn-dev/${VERSION}-rc.${RC}"
+svn status "${RELEASE_DIR}/svn-dev"
+svn commit "${RELEASE_DIR}/svn-dev" \
+  -m "Stage Apache Asyncband ${VERSION} release candidate ${RC}"
+```
+
+Confirm the candidate at `https://dist.apache.org/repos/dist/dev/incubator/asyncband/${VERSION}-rc.${RC}/` and verify every link prepared for the vote email.

.agents/skills/release/references/infrastructure.md

@@ -0,0 +1,34 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Release infrastructure
+
+This is a reference for the existing design, not a recurring release checklist. Consult it when changing configuration, troubleshooting publication, or arranging a new release manager's signing key.
+
+## crates.io Trusted Publishing
+
+Trusted Publishing is already configured for `asyncband`: repository `apache/asyncband`, workflow `release.yml`, and environment `release`. Routine releases reuse this configuration.
+
+`.github/workflows/release.yml` obtains a short-lived crates.io token through GitHub OIDC. Only a final `v${VERSION}` tag can enter the publish job; RC tags run package checks. `.asf.yaml` configures version-tag deployments and required reviewers for the `release` environment. Consult those repository files and the live crate settings when diagnosing a mismatch. See the [crates.io Trusted Publishing documentation](https://crates.io/docs/trusted-publishing) for changes to this setup.
+
+## Signing and ASF distribution
+
+Candidates are staged under `https://dist.apache.org/repos/dist/dev/incubator/asyncband/`; approved releases are promoted to `https://dist.apache.org/repos/dist/release/incubator/asyncband/`. The public verification key list is `https://downloads.apache.org/incubator/asyncband/KEYS`.
+
+The release manager uses an ASF-associated signing key published in the existing project `KEYS` file. For a new signing key, follow the [ASF release signing guide](https://infra.apache.org/release-signing.html), verify the fingerprint through an independent channel, and add the public key while preserving existing keys. Reuse established distribution areas and signing configuration; investigate a reported access or verification failure before proposing infrastructure changes.