# 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. - Workflow type: code - Services: GitHub, Dart - Categories: Engineering, Operations - Published: 2026-08-04 ## What it does - 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 you'll need - 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 ## Prompt 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. ## How to customize - 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 ## FAQ ### 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. Use this prompt in General Input: https://www.generalinput.com/prompts/keep-dart-tasks-in-sync-with-your-github-pull-requests