Keep Dart tasks in sync with your GitHub pull requests

Open a pull request and the linked Dart task moves to In Review, merging moves it to Done, and closing without merging sends it back to In Progress.

Deterministic Code
GitHubDartEngineeringOperationsData SyncNotifications & Alerts
PromptCreate

When a pull request is opened, closed, or merged in GitHub, I want a deterministic workflow that keeps the linked Dart task in sync so nobody on the team updates status by hand. Trigger it from a GitHub webhook subscribed to pull request events, covering opened, closed, and closed-with-merged.

Step one is to read the Dart task ID out of the pull request branch name, falling back to the pull request title if the branch does not contain one. Branches are named like feature/DART-123-new-login, so match the task ID token wherever it appears in the string. If no task ID is present in either place, stop immediately without doing anything else. This early exit matters: most pull requests in a repository are not linked to Dart work, and the workflow must not error or comment on them.

With a task ID in hand, call GitHub Get a Pull Request to read the current state of the pull request: title, author login, html_url, state, and the merged flag. Do not trust the webhook payload alone for the merge decision, read it back from the pull request. Then call Dart Get Task with the parsed ID to confirm the task actually exists. If the task is not found, stop quietly rather than failing loudly.

Resolve status names through Dart Get User Space Configuration rather than hardcoding them, so the workflow uses whatever statuses the workspace actually has. Pull the list of valid statuses and match case-insensitively against the ones meaning in review, done, and in progress. If the workspace has no matching status for a given transition, skip the status update but still write the comments.

Then apply the mapping with Dart Update Task. A pull request that was opened sets the task to the In Review status. A pull request that was closed with merged true sets it to Done. A pull request that was closed with merged false sets it back to In Progress. There is no judgement call anywhere: three known pull request states map to three resolved statuses.

On every transition, add a Dart Create Comment on the task recording the pull request title, the author, the link to the pull request, and the status the task was just moved to. Finally, post exactly one GitHub Create an Issue Comment back on the pull request confirming which Dart task was updated and to what status. Pull requests are issues in GitHub's API, so the issue comment operation works with the pull request number. One comment on the task and one comment on the pull request per event, never duplicates.

Additional information

What does this prompt do?
  • Reads the Dart task ID from your branch name or pull request title, so there is nothing extra for anyone to fill in.
  • Moves the task to In Review when the pull request opens, Done when it merges, and back to In Progress when it closes without merging.
  • Comments on the Dart task with the pull request title, its author, and a link every time the status changes, then replies on the pull request confirming which task was updated.
  • Skips any pull request with no task ID in it, so unrelated work is never touched.
What do I need to use this?
  • A Dart workspace and a login for it
  • A GitHub account with access to the repositories you want to watch
  • Statuses in Dart for work that is in review, done, and in progress (the workflow reads whatever your workspace already uses)
  • A habit of naming branches or pull request titles with the Dart task ID
How can I customize it?
  • Change which status each pull request event maps to, for example sending merged work to Ready to Ship instead of Done
  • Choose which repositories are watched
  • Reword the confirmation reply posted back on the pull request, or turn it off if your team finds it noisy

FAQs

What happens to pull requests that are not linked to a Dart task?
Nothing at all. If no task ID appears in the branch name or the pull request title, the workflow stops immediately and leaves the pull request alone. Only linked work gets updated.
Do I have to name my branches a specific way?
Just put the Dart task ID somewhere in the branch name or the pull request title, for example feature/DART-123-new-login. The rest of the name is entirely up to you and the rest is automatic.
Will this work if my workspace uses custom status names?
Yes. The workflow reads the statuses your Dart workspace actually has rather than assuming a fixed set, so you can map each pull request event to whichever names your team uses.
How is this different from Dart's built-in GitHub integration?
It covers the same linking idea, but you own the rules. You decide which status each event maps to and exactly what gets written back to the task and the pull request.
Will my team get duplicate comments?
No. Each pull request event produces exactly one comment on the Dart task and one reply on the pull request.

Related templates

Risk-check every dependency upgrade pull request in GitHub

When a bot opens a version bump pull request, we read the real documentation for that exact version and tell you whether it is safe to merge.

Context7
GitHub
Slack
Agentic Task
Privately nudge owners of stalled Dart tasks in Slack

Every weekday morning, an agent finds work that has quietly stopped moving in Dart and sends each owner a private Slack nudge, plus one summary for managers.

Dart
Slack Bot
Agentic Task
Turn Zendesk support tickets into triaged Dart product tasks

Every weekday morning we group the last day of support tickets into real product themes, then file or update the right task in your Dart backlog.

Dart
Zendesk
Slack Bot
Agentic Task
Turn finished Dart tasks into a weekly changelog doc

Every Friday, an agent reads the week's completed work in Dart, writes it up in plain language, and saves it as a doc your whole team can share.

Dart
Slack Bot
Agentic Task
Did the last Heroku deploy cause this Sentry error?

When a new Sentry error appears, we check your latest Heroku deploy, alert your team in Slack with the likely cause, and open a GitHub triage ticket.

Heroku
Sentry
Slack Bot
+1
Agentic Task
Turn Heroku deploys into a readable Slack changelog

Every time you ship to Heroku, we post a clear summary to Slack listing what changed, who deployed it, and whether it was a rollback.

Heroku
GitHub
Slack
Agentic Task

Stop updating task status by hand.

Let your pull requests move Dart tasks for you, from the moment they open to the moment they merge.

Explore more promptsCreate