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.

Additional information

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.

Frequently asked questions

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.

Stop letting pull requests sit ignored.

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