# 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]**.

## 0. Set up (skip if you're already connected)

If you don't already have live tool access for this, connect it first —
this prompt is only as real as the tools behind it:

1. Get a Tulina account: book a demo at https://tulina.ai/book.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this prompt uses —
   issue tracking and team messaging.
4. Separately, confirm your assistant already has read access to your
   code host — that part runs outside Tulina, through whatever access
   your assistant already has.

Once connected, your assistant has real tool access and the rest of this
prompt runs as written.

## 0b. Already on Tulina? Three things around the run

An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:

1. **Activate this process's connectors first.** Call
   `oto_connector(op="list")`, match it against the tools named in step 3
   above, and `oto_connector(op="select", name="...")` every one that
   isn't active yet. Selecting a connector does not mount its tools in the
   conversation you're already in — reach them through `oto_call` for this
   run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
   shows your active org's projects: pick the one this work belongs to
   rather than opening another, and keep its id. The project is where this
   process, the tables it writes to and the connectors it uses hang
   together.
3. **When the run is done, save it as a process — with its graph.** Write
   the body with `oto_procedure(op="set", ...)`, then attach it with
   `oto_project(op="link", project_id=..., target_type="procedure",
   target_ref="<your slug>")`. The body has to carry a drawing: read
   `oto_guide(op="read", slug="procedure-flowchart")` and follow it
   exactly — ONE untagged fenced block in that grammar, opening with the
   trigger and a quoted example of what you'd type to start a run. Tulina
   parses that drawing back into the graph it renders as the process's
   default view, which is what makes it come out in the same style as
   every other process in the app; a drawing the grammar can't read falls
   back to raw characters instead. Saving a process needs org-admin
   rights — without them, hand the finished body to someone who has them.

## 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.