Weekly Bitbucket changelog page in Confluence

Every Friday at 4pm, publish a weekly changelog page to Confluence built from the Bitbucket pull requests your team merged that week.

Deterministic Code
BitbucketConfluenceEngineeringProductDaily Digests
PromptCreate

Every Friday at 4pm, publish a weekly changelog page to Confluence built from Bitbucket pull requests merged that week. Use a cron trigger. No AI reasoning is required: the title prefix is the classifier, ordering is by merge date, and the template is fixed. Build this as a deterministic code workflow.

Step 1. List merged pull requests from the configured Bitbucket repository using the Bitbucket List Pull Requests operation. Use a BBQL query of state="MERGED" AND updated_on>="<ISO timestamp for 7 days ago>", sort=-updated_on, and pagelen=50 (that is the max for pull requests). Follow the HAL next link on the response to paginate until there is no next. Pull request state values are uppercase in Bitbucket.

Step 2. Group the returned pull requests by conventional-commit prefix parsed off the PR title. Recognize feat, fix, chore, docs, and refactor. Parse case-insensitively and tolerate an optional scope like feat(api): or fix(ui): — match a leading token of letters, an optional (scope) in parentheses, then a colon. Any PR whose title does not match one of the five known prefixes falls into an Other bucket. Within each group, keep the entries in merge-date order using updated_on descending.

Step 3. Format each entry as "PR title — author (link)". Use the PR's html link from the links.html.href field, and the author display_name. Skip groups that end up empty.

Step 4. Create a new page in Confluence using the Confluence Create Page operation. Title it "Changelog — week of YYYY-MM-DD" where YYYY-MM-DD is the current Friday's date. Set the parentId to the configured parent page and the spaceId to the configured space. Publish the page (not a draft).

The Confluence page body must be Confluence storage format (XHTML-like). Render each non-empty group as an <h2> heading with a friendly label (Features for feat, Fixes for fix, Chores for chore, Docs for docs, Refactor for refactor, Other for the fallback bucket) followed by a <ul> of <li> entries, one per pull request. Each <li> should read: PR title, an em dash, author name, then a link to the PR wrapped in an <a href="...">link</a> tag or similar.

Expose these as configurable inputs: the Bitbucket workspace slug and repository slug, the Confluence cloudId, the target spaceId, the parent page id, and the cron schedule. Everything else — the seven-day window, the prefix list, the classifier logic, the section labels, the page title format, and the storage-format template — is fixed inside the workflow.

Additional information

What does this prompt do?
  • Every Friday afternoon, gathers every pull request merged in your chosen Bitbucket repository over the past seven days.
  • Groups them into sections like Features, Fixes, Chores, Docs, and Refactor based on the prefix in each pull request title, with anything unrecognized dropping into an Other section.
  • Publishes a fresh Confluence page under your chosen parent page, with one line per pull request showing the title, author, and a link back to Bitbucket.
  • Gives non-engineers a clean, searchable release history without ever having to open Bitbucket.
What do I need to use this?
  • A Bitbucket workspace and the repository you want to pull merged pull requests from.
  • A Confluence space with a parent page where the weekly changelog pages should live.
  • Pull request titles ideally follow the feat / fix / chore / docs / refactor convention. Titles that do not match drop into an Other section, so nothing gets skipped.
How can I customize it?
  • The day and time it runs (default is Friday at 4pm).
  • Which Bitbucket repository the changelog covers.
  • Which Confluence space and parent page host the weekly history.

Frequently asked questions

Do our pull request titles need to follow a specific format?
It works best when titles start with feat, fix, chore, docs, or refactor (an optional scope like feat(api): is fine), but it is not required. Anything without a recognized prefix drops into an Other section, so nothing gets skipped.
Which pull requests get included each week?
Every pull request in the selected repository that was merged in the last seven days, ordered by merge date.
Where does the new page appear in Confluence?
As a child of the parent page you pick during setup, so the weekly changelogs pile up in one place and stay easy to browse.
What if we merge more than fifty pull requests in a week?
The workflow pages through all of them automatically, so even a busy release week produces one complete changelog.
Can this cover more than one repository?
The workflow ships pointed at a single repository. To cover more, duplicate it for each repo and point each copy at its own parent page in Confluence.

Turn merged pull requests into a weekly release story.

Ship this workflow and your team gets a fresh Confluence changelog every Friday, no copy-paste needed.