release

name	release
description	Create the GitHub release for the just-bumped version and see it published — push the release tag, create a GitHub release with auto-generated notes, wait for the PyPI publish workflow, and verify the released version with uvx. Use when the user says "release", "/release", or asks to create/publish the GitHub release.
allowed-tools	Bash(git *) Bash(gh *) Bash(uvx *) Bash(curl *)
disable-model-invocation	true

release

Automate README-DEV.md → "Release a new version of this repository" → step 4. Create a GitHub release. This runs after the version has been bumped (README steps 1–3, i.e. bump-my-version bump release --tag created the vX.Y.Z tag and bump minor moved the tree to the next .dev0). This skill does not bump the version — it is the natural follow-on to /push.

Push the release tag, create the GitHub release (which triggers PyPI publishing), watch the publish workflow to green, and verify the released version is live. Work through the steps in order; stop and report if a step can't be completed.

1. Preconditions & determine the release tag

Confirm the current branch is main:

git rev-parse --abbrev-ref HEAD

If not on main, stop and ask the user before releasing.

Confirm a clean working tree — the version-bump commits should already be in place:

git status --porcelain

If there is any output, stop and report the uncommitted files. Do not commit on the user's behalf.

Determine the release tag = the latest v* release tag reachable from HEAD:

git describe --tags --abbrev=0 --match 'v*'

Sanity-check it looks like a released version (vMAJOR.MINOR.PATCH, no .dev suffix) and show it to the user. If it carries a .dev suffix, the version wasn't bumped to a release — stop and tell the user to run README steps 1–3 first.

Guard against re-releasing an existing release:

gh release view <tag>

If the release already exists, stop and report — nothing to do. If you're unsure the tag matches the bump the user just made, confirm with them before proceeding.

2. Push branch and tags

git push origin HEAD --tags

If the push is rejected (e.g. remote is ahead), stop and report. Do not force-push on your own initiative.

3. Create the GitHub release

gh release create <tag> --title <tag> --generate-notes

--generate-notes auto-builds the release notes from merged PRs/commits since the previous release. Print the resulting release URL. Creating (publishing) the release is what triggers the PyPI publish workflow.

4. Wait for the PyPI publish workflow

The published release triggers the Publish to PyPI workflow (.github/workflows/publish.yml), which builds the distributions and publishes to PyPI via Trusted Publishing. Find the run and watch it to completion:

gh run list --workflow publish.yml --limit 5
gh run watch <run-id> --exit-status

• gh run watch --exit-status exits non-zero if the run fails.
• If it succeeds, continue to step 5.
• If it fails, inspect and diagnose:

gh run view <run-id> --log-failed

Report the real cause clearly (build/twine check failure, OIDC/Trusted-Publisher misconfig, etc.). Do not retry blindly — republishing the same version to PyPI will fail, so the fix usually involves the user (e.g. correcting the publisher config), not re-running the job.

5. Verify the published version

A green publish workflow means PyPI accepted the upload, but the index/CDN needs a moment to expose it. Verify in two phases — don't rely on uvx --refresh alone, which can silently resolve to the previous version if the index hasn't caught up.

<version> = the tag without the leading v (tag v1.8.0 → 1.8.0).

5a. Confirm the version is available on the PyPI index

The version-specific JSON endpoint returns 200 only once that exact version is published. Poll it, retrying a few times with a short sleep between attempts until it returns 200 (propagation typically takes seconds to a couple of minutes):

curl -sf -o /dev/null -w '%{http_code}\n' https://pypi.org/pypi/anki-addons-dataset/<version>/json

If it never appears within a sensible window, report that the publish workflow was green but the version isn't visible on PyPI yet, and stop.

5b. Pull it to this machine and verify end-to-end

Only after 5a returns 200, run the README's check so the just-published package is actually fetched and executed here:

uvx --refresh anki-addons-dataset info

--refresh bypasses uvx's cache so it fetches the newly published version. Confirm the version it prints equals <version>.

Done

Report the final state: the pushed tag, the release URL, the publish-workflow result, and the verified uvx version — or the first step that failed and why.