figlens-release · git:20261021.ff80197 · 2026-10-21 · sha256 c76f1c259dd4d2ee
figlens-release git:20261021.ff80197A
Immutable. This exact content never changes and is served at /api/v1/blob/c76f1c259dd4d2ee.
--- name: figlens-release description: Prepare, review and publish a figlens release through the Release Please PR, the draft release and the manual Publish Release workflow. Use when the user says "release", "prepare a release", "cut a release", "please release", or asks to publish a new figlens version. argument-hint: "[version]" metadata: targets: [claude, universal, pi] --- Prepare or review a figlens release. A version argument is the requested version, not permission to commit, merge, push or publish. Before acting, run `python3 scripts/ai-context.py release`. That topic is the source of truth for the automation; this skill is only the order of steps. ## 1. Find the pending release ```sh gh release list --limit 3 gh pr list --label 'autorelease: pending' --state open ``` The open Release PR holds the next version and its CHANGELOG entry. No PR: check the latest "Release Please" run (`gh run list --workflow release-please.yml --limit 3`) and the repository setting that lets Actions create pull requests. Dispatch the workflow only when the user authorizes it. Requested version: put a `Release-As: X.Y.Z` footer on the next commit to `main` (blank line before it; copy it into the squash message on a squash merge), then confirm the Release PR moves to that version. ## 2. Review the Release PR - The version follows the policy in the `release` topic; a breaking change needs migration notes in the CHANGELOG. - `Cargo.toml`, `Cargo.lock` and `npm/package.json` carry the same version. - Every user-visible `feat` and `fix` in `<last tag>..origin/main` is reflected in `README.md`, `skills/figlens/SKILL.md` and the wiki topics; fix stale docs on `main` first, then let the PR update. - CI on `main` is green. Report the version, the changelog entries and anything missing. Merge only when the user says so (`gh pr merge <n> --merge`). ## 3. Check the draft After the merge, follow the run until the "package" job finishes (`gh run watch`). Then: ```sh gh release view v<version> --json isDraft,assets --jq '.isDraft, (.assets[].name)' gh release download v<version> --dir samples/release-v<version> && (cd samples/release-v<version> && shasum -a 256 -c SHA256SUMS) ``` Expect five archives (macOS arm64/x86_64, Linux musl arm64/x86_64, Windows zip) plus `SHA256SUMS`. Unpack the archive for this machine and run `figlens --version` and `figlens tree <a sample .fig> --depth 1`. ## 4. Publish Only on the user's explicit go-ahead: `gh workflow run publish-release.yml -f tag=v<version>`. It publishes the draft, then Homebrew and npm. Watch it to the end and report each job; a failed channel is reported, never retried blindly.