Auto-summarize new pull requests in Microsoft Teams

When a pull request opens in Azure DevOps, an agent writes a plain-English summary and posts it to Teams so reviewers instantly know what to prioritize.

Agentic Task
Azure DevOpsMicrosoft TeamsEngineeringContent GenerationNotifications & Alerts
PromptCreate

This workflow runs every time a new pull request is opened in Azure DevOps. Use the Azure DevOps "Pull request created" service hook (the git.pullrequest.created event) as the trigger so the workflow fires the moment a PR is created.

When the webhook fires, take the pull request id, repository id, and project from the event payload and call Get Pull Request to load the full details: the title, the description, the source and target branches, the requested reviewers, the web URL that links back to the PR, and the last merge source commit.

Then call Get Commit on that source commit with the change list included so you can see exactly which files were added, edited, or deleted in this pull request. Use the file paths to understand which parts of the codebase the change touches.

Read the pull request title, description, and the list of changed files, then write a plain-English summary aimed at a reviewer who has not opened the code yet. Cover three things: what the pull request does in one or two sentences; which areas of the codebase it touches, grouping the changed files by folder or component so it is easy to scan; and anything worth a careful look, such as large diffs, changes to shared or sensitive files, database migrations, config, or dependency updates. Keep it concise and skimmable. The goal is to help reviewers prioritize, not to replace reading the diff.

Post the summary as a Microsoft Teams channel message using Create Channel Message in the code review channel. Start with the pull request title and its author, clearly name each requested reviewer so they know the review is waiting on them, include the plain-English summary and the grouped list of touched areas, flag anything risky, and end with a link back to the pull request in Azure DevOps so anyone can jump straight to it.

If the pull request has no requested reviewers yet, still post the summary and note that no reviewers are assigned so someone can pick it up. Format the message to be scannable at a glance: a short heading, a few bullets for the touched areas, and clear call-outs for anything that needs a careful look.

What does this prompt do?

  • Watches Azure DevOps and reacts the moment a new pull request is opened.
  • Reads the pull request and its changed files, then writes a plain-English summary of what changed and why it matters.
  • Calls out which areas of the codebase the change touches and anything that deserves a careful look.
  • Posts the summary to a Microsoft Teams channel, names the requested reviewers, and links straight back to the pull request.

What do I need to use this?

  • An Azure DevOps account with access to the repository you want to watch.
  • A Microsoft Teams workspace with a channel for code review updates.
  • Permission to turn on the Azure DevOps 'Pull request created' notification for that repository.

How can I customize it?

  • Choose which Teams channel the summaries land in.
  • Tune what the summary emphasizes, for example always flagging database migrations or dependency changes.
  • Decide how reviewers are called out and what to do when a pull request has no reviewers assigned yet.

FAQs

Does this work with private Azure DevOps repositories?
Yes. As long as you connect an Azure DevOps account that can see the repository, the workflow can read new pull requests and their changes.
Will reviewers get notified even if they don't open Azure DevOps?
Yes. The summary is posted right in your Microsoft Teams channel and names the requested reviewers, so they get the context without leaving Teams.
Does it summarize every pull request or only some?
By default it summarizes every new pull request as soon as it opens. You can narrow it to specific repositories or add rules about which ones to skip.
Is the summary good enough to skip reading the code?
The summary is meant to help reviewers prioritize, not replace the review. It highlights what changed and what to look at closely so reviewers can dive into the right files first.
What happens if no reviewers are assigned yet?
The workflow still posts the summary and notes that no reviewers are assigned, so the team can pick it up quickly.

Related templates

Run your weekly bug triage meeting on one Azure DevOps board

Work through untriaged Azure DevOps bugs in one two pane screen, set priority and owners as you go, then post the meeting outcome to Slack.

Azure DevOps
Slack Bot
App
Cross-project delivery health dashboard for Azure DevOps

See work items, pull requests and pipeline health for every Azure DevOps project on one screen, with stalled reviews and repeat build failures flagged.

Azure DevOps
App
Support bug intake and status portal for Azure DevOps

Let support agents file bugs straight from a Zendesk ticket, catch duplicates before submitting, and track status without an Azure DevOps license.

Azure DevOps
Zendesk
App
Nudge stalled Azure DevOps pull requests every weekday

Every weekday morning we check your open pull requests, work out who is actually blocking each one, and send that person a direct message in Slack.

Azure DevOps
Slack Bot
Agentic Task
Catch phishing domains impersonating your brand each morning

Every weekday we scan new security certificates for fake versions of your domain, check them for known abuse, and alert your team in Teams.

Censys
VirusTotal
Notion
+1
Agentic Task
Daily SonarCloud quality gate status board in Teams

Every weekday morning, post every failing SonarCloud project into Microsoft Teams, so builds that have been red for a week stop slipping past your team.

SonarCloud
Microsoft Teams
Deterministic Code

Stop letting pull requests sit ignored.

Give every reviewer instant context in Teams so code reviews start faster and nothing slips through the cracks.