## Description > AI-agent disclosure: this PR was authored by an automated agent (Claude Code) and has not been line-by-line reviewed by a human before submission. Releases of fast-check and its sibling packages will now actually be announced on Bluesky: the "Announce Release on Bluesky" workflow added in #6959 has never fired once. The announcement now goes out when the maintainer dispatches the Create Release workflow, right after the draft release is created and the tag pushed, and the wording is adjusted to match that timing — `🚀 New release on its way: fast-check v4.9.0`, followed by a link to the release notes. The linked release page goes live a few minutes later, once the publish pipeline flips the draft to published. Dry runs of Create Release skip the post. Why it never fired: the workflow listened to `release: published`, but releases are flipped from draft to published by `softprops/action-gh-release` inside the publish jobs using the default `GITHUB_TOKEN`, and GitHub suppresses events created with that token from triggering other workflows. Its `discussion_url != ''` guard was dead too, since #6975 dropped discussion creation on releases. Design: `announce-release-bluesky.yml` becomes a reusable `workflow_call` taking the release tag, invoked from a new `announce-release` job in `create-release.yml` — which now re-exports the tag computed by its changelog-extract step as a job output. Alternatives considered and rejected: publishing releases with a PAT so `release: published` fires (a new long-lived secret to manage), or wiring the announcement into the seven publish jobs of `build-status.yml` (couples the social post to the publish pipeline). Anchoring on the human-dispatched Create Release needs no new secret and leaves `build-status.yml` untouched. The Bluesky secrets are declared and passed explicitly to the called workflow rather than via `secrets: inherit`, so only the three `BLUESKY_*` secrets are in its reach. Impact level: patch, CI-only — no published package changes, hence no changeset. The PR stays focused on a single concern: making the Bluesky announcement flow fire. No automated tests were added: the change is workflow glue around the existing, already smoke-tested `post-bluesky.mjs`; YAML validity and the tag→URL/label mapping (including slashed tags like `packaged/v0.7.1`) were verified locally. <!-- Add any additional context here --> ## Checklist — _Don't delete this checklist and make sure you do the following before opening the PR_ - [ ] I have a full understanding of every line in this PR — whether the code was hand-written, AI-generated, copied from external sources or produced by any other tool - [ ] I flagged the impact of my change (minor / patch / major) either by running `pnpm run bump` or by following the instructions from the changeset bot - [ ] I kept this PR focused on a single concern and did not bundle unrelated changes - [ ] I followed the [gitmoji](https://gitmoji.dev/) specification for the name of the PR, including the package scope (e.g. `🐛(vitest) Something...`) when the change targets a package other than `fast-check` - [ ] I added relevant tests and they would have failed without my PR (when applicable) <!-- PRs not checking all the boxes may take longer before being reviewed --> <!-- More about contributing at https://github.com/dubzzz/fast-check/blob/main/CONTRIBUTING.md --> --------- Co-authored-by: Claude <noreply@anthropic.com>