Menu
Cut an xmris release — bump the version, run the full CI matrix via a release branch, and tag to trigger the PyPI publish. User-triggered only.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Write and reconcile the design document for a significant xmris change — the reader-facing explanation of why a decision was made. Use at the START of any change that adds vocabulary or a contract, picks between viable approaches, or spans multiple PRs; and again at the END of that work to reconcile the doc against what was actually built.
Add a new xmris processing/accessor function end-to-end following the project's architectural rules. Use when adding a new `.xmr` method or transform (e.g. a new apodization, phasing, Fourier, baseline, or fitting operation), or when asked to "add a processing function/method" to xmris.
Add or modify an xmris interactive visualization widget (AnyWidget) end-to-end following the project's conventions. Use when adding a new `.xmr.widget.*` component (e.g. a phaser, scroller, apodizer, or other canvas UI), or when working on an existing widget's Python/JS/CSS, accessor wiring, or docs.
Create or edit an xmris documentation notebook (MyST .md under docs/notebooks/) following the project's notebook conventions. Use when adding a tutorial/doc page, writing notebook tests for a function, documenting a new .xmr method, or restructuring existing doc notebooks.
| name | release |
| description | Cut an xmris release — bump the version, run the full CI matrix via a release branch, and tag to trigger the PyPI publish. User-triggered only. |
| disable-model-invocation | true |
Guided checklist for cutting a release. Publishing is automated via GitHub Actions (ci-publish.yml) using PyPI Trusted Publishing (OIDC) — you never run uv publish by hand; pushing a vX.Y.Z tag does it.
$ARGUMENTS is the bump level (patch | minor | major) or an explicit version (0.7.0). If empty, ask which.
Pushing branches and tags triggers CI and an irreversible PyPI publish. Confirm with the user before any push, and stop if a step fails.
Preconditions. On main, working tree clean, up to date with origin. Confirm the fast CI on main is green (gh run list --branch main --limit 3). Never bump a version while CI is red.
Determine the version. Show the current version (uv version) and the target implied by $ARGUMENTS. Confirm with the user.
Bump. uv version --bump <level> (or set the explicit version). Commit: chore: release vX.Y.Z.
Run the full matrix. Push a release/vX.Y.Z branch — this triggers the full Ubuntu/Windows/macOS × Py 3.10–3.13 matrix in ci-publish.yml. Wait for it and check results with gh run watch / gh run list. Note: macOS is allowed to fail (continue-on-error, upstream pyAMARES issue) — a red macOS leg alone does not block the release; everything else must be green.
Tag & publish. Once the matrix is green, tag and push:
git tag vX.Y.Z
git push origin vX.Y.Z
The tag triggers uv build --no-sources + uv publish to PyPI via OIDC. Watch the publish run to confirm success.
Wrap up. Confirm the new version is live on PyPI and the main/release branches are in the expected state. Summarize what shipped.