Auto-link merged GitLab merge requests to Linear issues

Build me a deterministic code workflow that closes the loop between GitLab merge requests and Linear issues. Every step is pattern-match, lookup, and CRUD across two systems, so no reasoning is needed.

Trigger: a GitLab webhook subscribed to the merge_request event, filtered down to the merged action only. Ignore opened, updated, approved, and closed-without-merge events.

Steps:

1. Use GitLab Get a Single Merge Request to fetch the MR by its project_id and iid from the webhook payload. Pull title, description, source_branch, web_url, merged_at, and the author.

2. Run a regex against the title, description, and source_branch to extract Linear issue keys that match the team-key pattern, for example [A-Z][A-Z0-9_]+-\d+. Make this configurable: accept either an explicit allow-list of team prefixes (ENG, OPS, DESIGN) or fall back to matching any uppercase prefix. Uppercase and deduplicate the extracted keys.

3. For each extracted key, call Linear Search Issues with the key as the query to confirm the issue exists and resolve it to a Linear issue id. Skip any key that does not resolve.

4. For each confirmed Linear issue, call Linear Add Comment to Issue with a markdown body like: 'Shipped in [<MR title>](<MR web_url>) at <merged_at>'. Include the author handle when available.

5. For each confirmed Linear issue, call Linear Add Link to Issue passing the MR web_url as the url and the MR title as the link title, so the MR shows up as an attachment in the Linear issue sidebar.

If no Linear issue keys are found, or none resolve, exit cleanly without posting anything. Be idempotent across re-deliveries of the same merge webhook: it is fine for Linear to dedupe attachments by URL, but the comment step should check existing comments on the issue for the same MR web_url before posting, to avoid duplicate shipped-in comments if GitLab redelivers the webhook.

Inputs the workflow should expose: the list of Linear team-key prefixes to match, the comment template string, and an optional allow-list of GitLab project paths so the workflow can be scoped to specific repos.

Additional information

What does this prompt do?

Watches GitLab and fires the moment a merge request is marked merged.
Reads the MR title, description, and source branch to find Linear issue keys like ENG-123 or OPS-45.
Posts a 'Shipped in <MR title>' comment on every Linear issue it finds, with the MR link and merge time.
Attaches the MR URL to the Linear issue so it appears in the issue sidebar alongside the team's other links.

What do I need to use this?

A GitLab account with permission to read merge requests on the projects you care about.
A Linear workspace where you can comment on issues and attach links.
The team key prefixes your team uses in Linear, for example ENG, OPS, DESIGN.

How can I customize it?

Change the comment wording, for example to mention the author or include the target branch.
Restrict the workflow to specific GitLab projects, target branches, or labels.
Limit which Linear teams are eligible by adjusting the list of key prefixes the workflow looks for.

Frequently asked questions

Will it pick up issue keys in the branch name too?

Yes. The workflow scans the merge request title, description, and source branch, so a branch named eng-123-fix-login still gets matched to ENG-123.

What if the same Linear issue is mentioned more than once in the MR?

Issue keys are deduplicated before posting, so each Linear issue only gets one comment and one attached link per merged MR.

What happens if the MR does not mention any Linear issue?

The workflow finishes cleanly without posting anything. No comment, no attachment, no noise.

Does GitLab's built-in Linear integration already do this?

GitLab's native Linear integration mainly handles issue state changes. This workflow adds the back-link, the shipped comment, and the attachment that close the loop for the rest of the team.

Can I include the merge timestamp or author in the comment?

Yes. The comment template can include the MR title, URL, author, target branch, and the time the MR was merged.