Auto-triage new GitHub PRs with risk labels and Slack summary
When a pull request is opened, an agent posts a plain-language summary, flags risk areas like migrations or auth, labels the PR, and pings Slack.
GitHub
Slack BotEngineeringNotifications & AlertsFeedback TriageContent GenerationBuild me an agent workflow that triages every new GitHub pull request the moment it is opened. I want plain-language summaries, risk flags, labels, and a Slack heads-up so reviewers know what they are walking into.
Trigger: a GitHub webhook on the pull_request event, filtered to the action 'opened'. The webhook payload tells the agent the repo and PR number.
First, skip the PR entirely if the author is a bot. Specifically ignore dependabot, dependabot[bot], renovate, renovate[bot], github-actions[bot], and any author whose login ends in -bot or -release. Exit cleanly with no comment, no label, no Slack message.
For human PRs, call Get a Pull Request on GitHub to fetch the title, body, author, base and head branches, additions, deletions, and the list of changed files. Use the changed file paths to reason about scope and risk.
Draft a short review comment with three sections. One: a plain-language summary of what the change does, written so a non-author reviewer can skim it in fifteen seconds. Two: an apparent risk level of low, medium, or high, with a one-line justification. Treat changes touching database migrations, auth or session code, payments or billing, secrets or environment config, infrastructure as code, or shared core libraries as elevated risk. Treat docs, tests, and copy-only changes as low risk. Three: a suggested reviewer focus, naming the two or three things a human should actually verify.
Post that draft on the PR using GitHub Create a Pull Request Review with event set to COMMENT. Do not approve and do not request changes. The review should be a single body comment, not inline comments.
Then label the PR using GitHub Add Labels to an Issue. Apply one risk label (risk:low, risk:medium, or risk:high) and one or more area labels inferred from the changed paths (for example area:frontend, area:backend, area:infra, area:docs, area:migrations, area:auth, area:payments). If a label does not exist, create it first with a sensible color.
Finally, post the same summary to Slack using Slack Bot Send a Message in the channel I configure (default #code-review). The Slack message should include the PR title as a link to the PR URL, the author, the risk level with an emoji (green for low, yellow for medium, red for high), the plain-language summary, and the suggested reviewer focus. Keep it tight, one Slack post per PR.
Make the bot author list, the risk path rules, the label naming, and the Slack channel easy to edit at the top of the workflow so I can tune it per repo without rewriting the agent.
What does this prompt do?
- Fires the moment a pull request is opened in your repo via GitHub webhook on the pull_request opened event.
- Reads the PR title, body, and changed files, then drafts a plain-language summary, a risk level, and a suggested reviewer focus.
- Posts the summary back on the PR as a comment-style review and applies risk and area labels automatically.
- Sends the same summary to a Slack channel with a direct link so reviewers can jump in without opening GitHub first.
- Skips noisy PRs from dependabot, renovate, and release bots so humans are not pinged for routine bumps.
What do I need to use this?
- A GitHub account with admin access to the repos you want triaged, so you can install the webhook on pull_request events.
- A Slack workspace with a Slack Bot connection authorized to post in the review channel.
- A code review channel in Slack where the agent should post summaries.
- Optional: an existing label set in GitHub for risk tiers and areas, or let the agent create them on first run.
How can I customize it?
- Adjust the risk heuristics: which paths count as high risk (migrations, auth, billing, infra) versus low risk (docs, tests, copy).
- Change the bot allowlist or denylist to skip more accounts, like Snyk or your internal release tooling.
- Route summaries to different Slack channels per repo, per team, or only when risk is medium or higher.
- Tune the review tone: terse one-paragraph summary, bullet checklist for reviewers, or a longer narrative.
FAQs
Does this approve or block PRs?
How does the agent decide the risk level?
Will it spam us for dependabot bumps?
What if the labels do not exist yet?
Can I use this on multiple repos?
Related templates
When someone leaves, we check which shared passwords they used in their final months and post a ranked rotation list to your security channel.
Every Monday, check every S3 bucket for public exposure, missing encryption and weak backup settings, then get the risks ranked in Slack.
Twice every weekday, the conversations from your social inbox land on the right HubSpot contact timelines, with a Slack recap for sales.
Every morning, find the addresses that hard bounced or filed a spam complaint, update the matching HubSpot contacts, and post a short Slack recap.
Every weekday at 4pm, spot the threads that went quiet, stage a ready-to-send nudge in your mailbox, and get a ranked Slack recap.
When you merge a fix in GitHub, this agent checks the matching dead-letter queue, replays the failed messages, and reports back on the pull request and in Slack.
Stop reading every PR cold.
Connect GitHub and Slack once, and Geni triages every new pull request the moment it opens.