Skip to content
Tulina
Book a demo
← Processes

Merged PRs move tickets and post a digest

Every merged pull request is matched to its ticket, the ticket moves forward with a comment naming the PR, and the team gets one daily summary of what shipped.

Book a demo
Linear→Slack
Starts
Pull request merged
Steps
4
Checks and gates
0
A person decides
Never, runs alone

Trigger · Event

Pull request merged

A merge fires the run as it lands, so the board reflects it before anyone asks where it got to.

Claude runs the rest autonomously

  1. 1

    AI lists the day's merged pull requests.

    Every pull request merged in the last day, across every repo that matters, is listed.

  2. 2

    AI matches each PR to its ticket.

    Linear

    Linear

    Each pull request is paired with its ticket, by an explicit reference first and a careful keyword match against open tickets otherwise.

  3. 3

    AI moves each matched ticket forward.

    Linear

    Linear

    Each matched ticket gets a comment naming its PR and moves one step when merged, further when confirmed live.

  4. 4

    AI posts one summary of what shipped.

    Slack

    Slack

    The team gets one short message a day, grouped by repo, naming what shipped and where it stands.

Keeping a board honest against what actually shipped is a standing chore: someone has to remember which PR closed which ticket, click into each one, move it, and then separately tell the team what landed. On a busy day, the last part is the first one to get skipped.

Both halves already exist as data. A code host like GitHub already knows exactly what merged and when; an issue tracker already knows every open ticket's status. The work is reading one, matching it to the other and writing back, the same join every day, at whatever hour nobody wants to do it by hand. That makes it a natural job for an AI agent sitting between the code host and Linear.

What you get

Every merged pull request is reflected on the board, the matching ticket moves forward with a comment explaining why, and the team gets one short summary of what shipped.

What the merged pull request automation reads

The run lists every pull request merged in the last day, across every repo that matters, with its title, description and merge time. The code host is read through access the assistant already has; it is not something Tulina connects to. The issue tracker and the team messaging tool are the two connections made in Tulina.

The lookback stays short on purpose, a day rather than a week. That is what makes the run idempotent: triggered twice by accident, the second pass re-confirms what the first already did instead of reprocessing a growing backlog.

Matching each pull request to its ticket

The first place to look is the pull request itself. Most PRs opened against a real ticket mention it somewhere in the title or description, and that explicit reference is a fast, precise match.

Without one, the agent compares the PR title against the team's open tickets by keyword, and takes that match only when it is genuinely confident. Matching discipline is where this earns trust or loses it: a wrong match moves the wrong piece of work forward, and the person who notices is rarely the one who ran the automation. An unmatched PR leaves the board alone and still appears in the summary, so nothing merges silently.

None of that matching is specific to Linear. An explicit reference first and a careful keyword fallback second works the same way against whichever tracker the assistant can reach.

Moving tickets forward, and only forward

Before changing anything, the agent reads the ticket's current state. A ticket already further along than "code merged" would suggest (in review, waiting on a specific person, already shipped) stays exactly where it is. The job is catching the board up, never overriding a call a human made more recently than this run.

Every move is preceded by a comment naming the specific pull request, with its title and link. A status that changes with no trace of why is indistinguishable from a status that is wrong.

The target state follows what is actually known. Merged is one signal; confirmed live in a preprod or staging environment is a stronger one, and the agent does not claim it without checking. Some repos deploy the moment a pull request lands on the main branch, others need a separate step first, and the two are easy to conflate unless each repo is checked. Telling them apart is what keeps "Done" meaning done.

One summary of what shipped

The team gets one short message in Slack, grouped by repo, skipping repos with nothing merged. Each pull request appears with its title, its ticket if it has one, and whether it is merged or confirmed live.

On a day when nothing merged anywhere, the message says that too. A routine that stays quiet on a quiet day is indistinguishable from one that is broken.

The prompt

The real prompt behind the steps above, detailed enough that an agent with the same tools can run it as written. The Run buttons copy the full version, which also carries the steps for connecting those tools.

# Turn merged into Slack notif and ticket update

You have access to issue tracking and team messaging, plus your own read
access to wherever your team's code lives (most coding assistants already
have this — a code host isn't something Tulina connects to). Run this
for **[your repos]**.


## 1. List the day's merged pull requests

- Pull every pull request merged in the last day, across every repo that
  matters — title, description, and merge time.
- Keep the lookback window short (a day, not a week). That's what makes
  this idempotent: run it twice by accident and the second pass just
  re-confirms what the first already did, instead of re-processing a
  growing backlog.

## 2. Match each PR to its ticket

- Check the PR title and description first for an explicit ticket
  reference — most PRs opened against a real ticket mention it
  somewhere, and that match is fast and precise.
- If nothing explicit turns up, compare the PR's title against your
  team's open tickets by keyword. Only take this match if you're
  genuinely confident — a wrong match is worse than leaving a PR
  unmatched, since it moves the wrong piece of work forward.
- A PR with no confident match still counts for the summary in step 4 —
  it just doesn't touch the board.

## 3. Move each matched ticket forward

- Before changing anything, read the ticket's current state. Never move
  a ticket backwards, and never touch one that's already further along
  than "code merged" would suggest.
- Leave a comment naming the specific PR — title and link — before
  changing status. A status that changes with no trace of why is
  indistinguishable from a status that's wrong.
- Decide the target state from what you actually know: merged alone is
  one signal, confirmed live in your preprod or staging environment is a
  stronger one. Don't claim the stronger one without checking — some
  repos deploy the moment a PR lands on the main branch, others need a
  separate step first, and the two are easy to conflate if you don't
  check per repo.

## 4. Post one summary of what shipped

- One short message, grouped by repo, skipping repos with nothing
  merged.
- For each PR: title, the ticket it maps to if any, and whether it's
  just merged or confirmed live.
- If nothing merged anywhere today, say that too — a routine that stays
  quiet on a quiet day is indistinguishable from a routine that's
  broken.

## Output

Report: how many PRs found, how many matched to a ticket, how many
tickets moved, and anything skipped and why.

Why run it with Tulina

A prompt helps one person. A process moves a team.

Pasted into a chat, the prompt above works once, for whoever pasted it. In Tulina, "Merged PRs move tickets and post a digest" becomes a process the team shares, that keeps its history, runs on its own, and stays inside the same security perimeter as the tools it calls.

  • The whole team works on the same one

    PersonalTeamOrganisation

    A process lives where it belongs: yours, your team's or the whole organisation's. Whoever runs it can improve it, and everyone starts from the best version instead of explaining the job again.

  • Every edit is a version

    v1v2v3

    Each change is a new version with the previous one kept, so a bad edit is undone by restoring an earlier one. Every run records the version it followed, and what a run teaches goes back into the process.

  • It runs without you

    schedulewebhookon demand

    A hosted agent runs the process on Tulina's own infrastructure, on a schedule or when an event arrives, and keeps going when you close the chat. Nothing to host. Every run is tracked to its outcome.

  • Inside the same security perimeter

    vaultrolesrun log

    Credentials stay in the vault, never in the prompt. Roles decide who may run what, every call is logged, and a step a person has to approve waits for that person.

Questions about updating tickets from merged pull requests

Yes. An agent with access to the issue tracker and read access to the code host can list the day's merged pull requests, match each one to its ticket, leave a comment naming the PR, and move the ticket forward. The team then gets one short summary of what shipped.

It looks for an explicit ticket reference in the PR title and description first, which is fast and precise. Without one, it compares the title against open tickets by keyword and only takes a match it is confident in. A PR with no confident match leaves the board alone but still appears in the summary, so nothing merges silently.

No — the agent reads a ticket's current state before touching it, and only ever moves work forward from where it already was.

A native integration usually just links a PR to a ticket. This also decides what to do about it — move the ticket or don't, based on whether the code is merged or confirmed live — and writes a plain-language summary a non-engineer can read.

Also on Linear

Other processes that run mainly on Linear. The tools they share with this one are lit.

See Tulina in a 30-minute demo.

Book a demo