Auto-draft release notes from GitLab to Notion and Slack

Every time you publish a release in GitLab, get a polished Notion page and a Slack announcement that reads like product copy, not a list of branch names.

Agentic Task
GitLabJiraNotionSlackEngineeringProductContent GenerationNotifications & AlertsAI Reports

Build an agent workflow that drafts and publishes release notes whenever I publish a new release in GitLab.

Trigger: a GitLab webhook on the project's Release Hook event. The webhook payload includes the project id, the new release tag, the release name, the release description, and the released_at timestamp. The agent should only run on action == "create".

What the agent should do, step by step:

1. Read the incoming Release Hook payload to get the project id, the new tag name, and the released_at timestamp.

2. Call GitLab List Releases for the same project, sorted by released_at descending, and find the most recent release whose tag is not the new one. Treat that release's released_at as the start of the merge window. If there is no prior release, use the project's creation date as the start instead.

3. Call GitLab List Project Merge Requests with state=merged, scope=all, and updated_after / updated_before (or merged window) bounded by the prior release's released_at and the new release's released_at. Paginate until exhausted.

4. For each merged MR, call GitLab Get a Single Merge Request to read the full title, description, author, and labels. Look for a Jira issue key in the title or description using the pattern of uppercase letters, a dash, and digits (e.g. ABC-1234). If a key is found, call Jira Get Issue with that key and grab the summary so the human-readable feature name can be used instead of the raw MR title.

5. Group the resulting entries into three buckets: Features, Fixes, and Chores. Use the MR title prefix or labels to decide (feat / feature -> Features, fix / bug -> Fixes, chore / deps / refactor / ci -> Chores). When in doubt, default to Features. Draft a short two or three sentence headline summary of the release in product-marketing tone, naming the biggest user-visible improvement.

6. Call Notion Create a Page under a configured Release Notes parent page. The page title should be the release tag and name (for example "v2.4.0 - Faster onboarding"). Then call Notion Update Page Content as Markdown on the new page with the body: headline summary, then a Features section, then Fixes, then Chores. Each entry should be a bullet with the friendly name (from Jira summary when available, otherwise the MR title) and a link to the GitLab MR.

7. Call Slack Send a Message in the configured release-announcements channel. The message should have the release title, a one-line summary, the top three highlights (pick from Features first, then Fixes, skipping anything in the Chores bucket), and a link to the new Notion page. Keep the Slack message short. The Notion page is the long form.

Inputs to ask me for on first run:

- The GitLab project (id or path) and a credential to read it.

- The Notion parent page id where the release notes archive should live.

- The Slack channel for the announcement.

- Whether Jira lookups should run, and if so, the Jira workspace credential.

Rules: keep dependency-bump and chore MRs out of the Slack highlights, but include them in the Notion page so the changelog is complete. If a release fires twice for the same tag, do not create a duplicate Notion page or repost to Slack.

Additional information

What does this prompt do?
  • Watches your GitLab project and runs the moment you publish a new release.
  • Pulls every merge request that shipped since the last release and groups them into Features, Fixes, and Chores.
  • Looks up Jira tickets mentioned in each MR so feature names read like real product updates instead of branch names.
  • Publishes a clean release notes page in Notion under the parent page you choose.
  • Posts a Slack announcement with the headline, top three highlights, and a link to the full notes.
What do I need to use this?
  • A GitLab account with permission to manage webhooks on the project you want to track.
  • A Notion workspace and a parent page where release notes should live.
  • A Slack workspace and the channel you want announcements posted in.
  • A Jira account if your merge requests reference Jira issue keys (optional, but it makes the notes read better).
How can I customize it?
  • Pick which Slack channel gets the announcement and which Notion parent page holds the release notes archive.
  • Tweak how merge requests are grouped, for example splitting out Performance or Security as their own section.
  • Adjust which kinds of changes get hidden from the Slack highlights, like dependency bumps or internal chores.
  • Change the tone of the headline summary, from formal product update to casual changelog.

Frequently asked questions

What if my team does not use Jira?
That is fine. The Jira lookup only runs when a merge request mentions a Jira ticket key. Without Jira, the notes use the merge request titles directly.
Does this work for self-managed GitLab, not just GitLab.com?
Yes, as long as your GitLab instance can send outgoing webhooks to our platform when a release is published.
Will it post every release, including draft or test ones?
It runs whenever GitLab fires the release webhook. You can add a check in the prompt to skip releases tagged as draft or pre-release if you only want production announcements.
Can the Slack announcement go to more than one channel?
Yes. Tell the agent which channels you want and it will post to each of them. The Notion page is shared as a single source of truth across them.
What if I want the Notion page formatted differently?
The agent writes the page in Markdown, so you can ask it to change the section order, add an emoji per section, include contributor names, or anything else you can describe in words.

Stop hand-writing release notes after every deploy.

Connect GitLab, Notion, and Slack once, and Geni ships polished release notes the moment you cut a tag.