Comparing changes

## Summary - Replaces the custom `tasks/gen-release-notes` bash script (which shelled out to the Claude Code CLI) with [communique](https://github.com/jdx/communique), a purpose-built Rust tool for AI-editorialized release notes - Adds `communique.toml` with project context and `emoji = false` default - Simplifies the `create-release` CI job: creates a draft release from CHANGELOG.md as a baseline, then enhances it via `communique generate --github-release` with `continue-on-error: true` so CHANGELOG.md content remains as fallback if communique fails ## Test plan - [ ] Verify `mise install` picks up communique - [ ] Test locally with `communique generate v2.16.2 --dry-run` to confirm it generates notes for a past release - [ ] Review workflow changes to confirm the fallback pattern is correct 🤖 Generated with [Claude Code](https://claude.com/claude-code)  --- > [!NOTE] > **Low Risk** > CI-only changes that affect release-note generation; failures should degrade to CHANGELOG-based notes due to the explicit fallback and `continue-on-error`. > > **Overview** > Draft GitHub releases are now created from the latest `CHANGELOG.md` section and then optionally *enhanced* via `communique generate --github-release` (with `continue-on-error` so the CHANGELOG text remains the fallback). > > This removes the custom `tasks/gen-release-notes` script and its dependency on installing/running the Claude Code CLI, adds `communique.toml` project context (with emojis disabled), and installs `communique` via `mise.toml`. > > Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 83644f5. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).  --------- Co-authored-by: Claude Sonnet 4.6 <[email protected]> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>

@jdx

### 🔍 Other Changes - replace gen-release-notes with communique by [@jdx](https://github.com/jdx) in [#504](#504)

…d release (#506) ## Summary - The v2.17.1 release CI run failed because `gh release create --draft "v2.17.1"` created a release with tag `untagged-d8ea426c8964292e5b9a` instead of `v2.17.1` - `taiki-e/upload-rust-binary-action` could not find the release by tag name, failing all `build-and-publish` matrix jobs - Root cause: the new `communique`-based workflow calls `gh release create` almost immediately after checkout, whereas the old workflow had a ~60s `npm install -g @anthropic-ai/claude-code` step first. Without that delay, `gh` hits a race condition where GitHub's Releases API hasn't indexed the newly-pushed tag yet, so it falls back to creating an `untagged-*` draft ## Fix Add `--target "$GITHUB_SHA"` to `gh release create`. This anchors the release to the exact commit SHA from the workflow trigger, bypassing the GitHub Releases API's tag lookup entirely. The release is still associated with the tag name `v2.17.1` but doesn't depend on the API having indexed the tag yet. ## Test plan - [ ] Verify next release run creates a draft release with the correct tag (not `untagged-*`) - [ ] Confirm `taiki-e/upload-rust-binary-action` can find the release and upload binaries 🤖 Generated with [Claude Code](https://claude.com/claude-code)  --- > [!NOTE] > **Low Risk** > Small CI workflow change limited to release creation behavior; low risk aside from potentially changing which commit a tag’s release points to if the tag is mis-pushed. > > **Overview** > Ensures the `publish-cli` workflow always creates draft GitHub releases for the exact commit that triggered the run by adding `--target "$GITHUB_SHA"` to `gh release create`. > > This avoids occasional `untagged-*` draft releases (and downstream publish failures) when the tag hasn’t propagated/indexed yet at release-creation time. > > Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 571ac7e. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).  Co-authored-by: Claude Sonnet 4.6 <[email protected]>

@jdx

### 🐛 Bug Fixes - **(publish)** anchor gh release create to GITHUB_SHA to avoid untagged release by [@jdx](https://github.com/jdx) in [#506](#506)

…_name (#508) ## Summary - Previous fix (#506) added `--target "$GITHUB_SHA"` to `gh release create`, but the releases are still created as `untagged-*` - Root cause (revised): something creates a GitHub release for the tag ~60 seconds before the `publish-cli` workflow starts (timestamps: v2.17.1 release at 12:36:44, workflow start at 12:37:44; v2.17.2 release at 13:07:56, workflow start at 13:08:47). When `gh release create "v2.17.x"` finds an existing release for that tag, it silently creates a new `untagged-*` draft as a fallback instead of failing - Fix: call `gh api repos/${{ github.repository }}/releases --method POST` directly with explicit `-f tag_name=` and `-f target_commitish=` fields. This bypasses the `gh release create` wrapper entirely and guarantees the `tag_name` is set correctly regardless of pre-existing releases ## Test plan - [ ] Verify next release creates a draft with `tag_name: v2.x.x` (not `untagged-*`) via `gh api repos/jdx/usage/releases --jq '.[0]'` - [ ] Confirm `taiki-e/upload-rust-binary-action` finds the release and uploads binaries successfully 🤖 Generated with [Claude Code](https://claude.com/claude-code)  --- > [!NOTE] > **Low Risk** > Small, workflow-only change affecting how GitHub releases are created; primary risk is misconfigured API parameters causing draft release creation to fail. > > **Overview** > Fixes the `publish-cli` workflow’s draft release creation to avoid accidental `untagged-*` releases when a release already exists for a just-pushed tag. > > Replaces `gh release create` with a direct `gh api POST /repos/{owner}/{repo}/releases`, explicitly setting `tag_name`, `target_commitish`, and the changelog-derived release body before continuing with the existing release-notes enhancement and publish steps. > > Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 8ecbb58. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).  Co-authored-by: Claude Sonnet 4.6 <[email protected]>

@jdx

### 🐛 Bug Fixes - **(publish)** use gh api directly to create release with explicit tag_name by [@jdx](https://github.com/jdx) in [#508](#508)

## Summary - After migrating to communique, draft releases were getting `untagged-*` placeholder tag names because the workflow calls the API within ~5s of checkout, before GitHub has indexed the tag - The old workflow had ~90s of built-in delay (npm install + Claude CLI generation) that masked the race condition - Adds a retry loop that creates the draft, verifies `tag_name` matches, and deletes + retries (up to 30 attempts × 5s) if it got an `untagged-*` placeholder ## Test plan - [ ] Trigger a tag push and verify the draft release is created with the correct tag name - [ ] Verify `taiki-e/upload-rust-binary-action` finds the release successfully in build-and-publish jobs 🤖 Generated with [Claude Code](https://claude.com/claude-code)  --- > [!NOTE] > **Low Risk** > Workflow-only change that adds a bounded retry/delete loop to handle a GitHub indexing race; main risk is longer CI time or failure if the GitHub API behavior changes. > > **Overview** > The `publish-cli` GitHub Actions workflow now retries draft release creation after a tag push, verifying the created release’s `tag_name` matches the pushed tag. > > If GitHub returns an `untagged-*` placeholder, the workflow deletes the draft release, waits 5 seconds, and retries up to 30 times before failing with an explicit error. > > Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit a40bd07. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).  Co-authored-by: Claude Sonnet 4.6 <[email protected]>

@jdx

### 🐛 Bug Fixes - **(publish)** retry draft release creation until tag is indexed by [@jdx](https://github.com/jdx) in [#510](#510)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on Feb 18, 2026

This comparison is taking too long to generate.

Uh oh!