Announce merged Bitbucket PRs and close the Linear ticket

The moment a Bitbucket pull request merges into main, post a short release note to Slack and mark the linked Linear issue as done.

Agentic Task
BitbucketSlack BotLinearEngineeringProductNotifications & AlertsData Sync
PromptCreate

Trigger: a Bitbucket webhook fires on the pullrequest:fulfilled event (a pull request has been merged). One event = one run.

First, gate on the destination branch. Read the destination branch name from the webhook payload. If it is not main or master, stop immediately and do nothing — this workflow is only for release merges, not intermediate feature-to-feature merges.

Then pull the merged PR's full context from Bitbucket. Use Get Pull Request (bitbucket) to fetch the title, description, author display name, merge commit hash, source branch, destination branch, and the html link back to the PR. Use List Pull Request Commits (bitbucket) to get the commits that were included in the merge (author, short message, hash).

Detect a Linear issue reference. Scan the PR title, the source branch name, and the PR description in that order for the first match of a Linear-style key: an uppercase team prefix of two to six letters followed by a dash and a number (for example ENG-123, PROD-45, DES-9). Remember whether you found one — the rest of the workflow branches on this.

Map the Bitbucket author to a Slack user. Take the author's display name from the PR and use Look Up User by Email (slackbot) if you can derive an email, otherwise scan the Slack workspace user directory for a real_name or display_name that clearly matches (case-insensitive, allow small differences in spacing or middle initials). If you find a confident match, remember the Slack user id so you can @-mention them (<@USERID>). If not, just use their plain display name in the message — never guess wrongly.

Draft the release note. Keep it to three or four short lines: one line naming what shipped in plain language (derived from the PR title and description, not a copy-paste of the branch name), one line crediting the author with the @-mention, and a line with a link back to the PR. If a Linear key was detected, mention it in the note. The tone is a shipping announcement for the team, not a marketing blurb.

Post the note with Send a Message (slackbot) to the configured release announcement channel. Then use Get Permalink (slackbot) on the message you just posted to get a permanent link — you'll use it in the Linear comment.

If a Linear issue reference was detected: use Update Issue (linear) to transition that issue to the Done state (look up the workflow state id for the target team's Done state), and use Add Comment to Issue (linear) to add a comment that links the Bitbucket merge commit URL and the Slack release note permalink. Keep the comment factual: one line saying it shipped, plus the two links.

If no Linear issue reference was found, skip the Linear step entirely and finish. The Slack announcement still goes out — that path is not a failure.

Additional information

What does this prompt do?
  • Fires the moment a pull request merges into main or master in Bitbucket, and skips PRs merged into any other branch.
  • Drafts a short, human-friendly release note from the PR title, description, author, and commit list, and posts it to your chosen Slack channel with a link back to the PR.
  • Detects a Linear issue reference (like ENG-123) in the PR title, branch name, or description and marks that issue as Done, adding a comment that links the merge commit and the Slack announcement.
  • @-mentions the author in Slack by matching their Bitbucket display name to a Slack user, so the right person gets credit.
What do I need to use this?
  • A Bitbucket workspace with permission to receive pull request webhooks on the repositories you care about.
  • A Slack workspace and a release announcement channel the bot has been added to.
  • A Linear workspace where your engineering team tracks issues (optional; skipped automatically if no Linear reference is found in the PR).
How can I customize it?
  • Change which Slack channel receives the announcement, or route different repositories to different channels.
  • Adjust which branches count as a release (default: main and master).
  • Tune the tone and length of the release note, or add a section listing individual commits.

Frequently asked questions

What happens if the pull request is merged into a branch other than main or master?
Nothing. The workflow only runs on merges to main or master by default, so feature-to-feature merges and staging merges are ignored. You can add other branch names if your team uses a different naming convention.
What if the pull request has no Linear issue reference?
The Slack announcement still goes out. The workflow simply skips the Linear step when it can't find an issue key like ENG-123 in the PR title, branch name, or description.
How does it know which Slack user to @-mention?
It compares the Bitbucket author's display name against your Slack workspace's user directory. If it finds a confident match it @-mentions that person; otherwise it falls back to their plain name so the announcement still reads naturally.
Will this update the Linear issue even if I forgot to link it in the PR?
Only if the issue key appears somewhere in the PR title, branch name, or description. Adding your team's issue prefix to your branch names (like eng-123-fix-typo) is the easiest way to make sure this always works.
Does it work with private Bitbucket repositories?
Yes. It uses the same access as your Bitbucket account, so any repository you can see in Bitbucket is available to the workflow.

Close the loop between shipping and tracking.

Every merge deserves an announcement and a clean ticket. Let the workflow write both while you keep coding.