一键导入
release
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.