version-upgrade

Version Upgrade

Release one Rustwright version through the repository's existing PyPI and npm workflows. Treat "npm and Node.js" as one target: npm is the registry for the Node.js package. The two release targets are Python on PyPI and Node.js on npm. Do not publish rustwright-core to crates.io.

Arguments and mode

Read $ARGUMENTS for an exact SemVer version and an optional mode.

• Accept stable versions such as 0.1.1 and prereleases in the shared Cargo/npm/PyPI subset: 0.2.0-alpha.1, 0.2.0-beta.1, or 0.2.0-rc.1. Reject other SemVer prerelease labels because PyPI may not accept or may ambiguously normalize them.
• If the caller asks only to check, verify, or report a release or registry status, enter verify-only mode. Perform read-only GitHub, Git, PyPI, and npm queries and return the result without creating a branch, changing a file, dispatching a workflow, merging, tagging, or publishing.
• If no version is supplied, use the helper's default: increment a stable patch version or the final numeric prerelease component.
• Treat prepare, PR only, or dry run as prepare-only mode. Stop after the release PR and both successful preview artifact dry runs.
• Enter full-release mode only when the caller explicitly says publish, release now, or full release in the current request. Invoking this skill, asking for a version bump, or omitting a mode never by itself authorizes an irreversible registry publication; default those cases to prepare-only mode.
• Do not pause for choices that can be derived from the repository. Stop only for a dirty worktree, missing authorization or secret, failed validation, a required human review, or another condition that makes publishing unsafe.

1. Inspect current state

1. Read AGENTS.md and docs/RELEASING.md; repository instructions and the current workflows override examples in this skill.
2. Require a clean worktree. Never discard local changes.
3. Fetch origin/main and all tags. Start from the current origin/main, not a stale local branch.
4. Inspect .github/workflows/release-pypi.yml and .github/workflows/release-npm.yml. Both must still publish from the same v<version> tag.
5. Search open and merged release PRs, Git tags, PyPI, and npm before deciding where to start. For PyPI, compare every release key after canonicalizing both sides with packaging.version.Version; for example, PyPI may represent 0.2.0-alpha.1 as the equivalent 0.2.0a1. Compare npm versions with SemVer rules.
6. Require monotonic releases across all three histories. A new target must be strictly newer than every release version in Git tags, PyPI, and npm. A prepared or tagged target may equal the newest version, but must never be published if any newer release already exists in any history. Treat an invalid v* release tag as a blocker rather than silently ignoring it.
7. Classify the target as new, on an open release PR, prepared on main, tagged or publishing, partially published, or fully published. Reuse an existing PR only after inspecting its complete commit history and diff. Its head must be in this repository, its base must be current main, every version field must equal the target, and its diff must contain only the expected version files. A filename allowlist is not sufficient: inspect every hunk and require changes only to the exact version fields plus the two local package entries regenerated in the lockfiles. Reject dependency changes, unrelated lines in an allowed file, mode changes, renames, binaries, or extra commit content. When uncertain, reproduce the bump from the PR base in a clean temporary worktree and compare the resulting patch. Rerun every check and preview against its current head. Treat an unexpected file, commit, base, or fork as a blocker rather than inheriting it. If the target is already consistent on origin/main but has no tag or registry publication, treat it as a prepared release and resume at the final merged-commit dry runs in section 4. If it is fully published, report success without mutation. Handle partial publication as described below. Never reuse an equivalent published version or move a release tag.
8. Before resuming any existing tag, validate its provenance. Require an annotated v<version> tag whose target commit is reachable from current origin/main, contains the same target in every version field, and matches the headSha of its tag-triggered release runs. Stop on a lightweight tag, mismatched metadata or run SHA, unreachable commit, or unexpected tag target. Do not approve or rerun publication from an unverified tag.