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.

Agentic Task
GitHubSlack BotEngineeringNotifications & AlertsFeedback TriageContent Generation

Build 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.

Additional information

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.

Frequently asked questions

Does this approve or block PRs?
No. The agent posts a comment-style review using Create a Pull Request Review, which leaves an unblocking comment. It never approves or requests changes, so your branch protection and human reviewers stay in charge.
How does the agent decide the risk level?
It looks at the file paths and diff stats from Get a Pull Request and checks for sensitive areas you define, like database migrations, auth code, payment logic, or config files. You can edit the rules in the prompt to match your codebase.
Will it spam us for dependabot bumps?
No. The agent checks the PR author and skips dependabot, renovate, and any other bot accounts you list. Routine dependency PRs do not trigger a Slack message or a review comment.
What if the labels do not exist yet?
You can either create the risk and area labels ahead of time in GitHub, or let the agent create them on first use. Add Labels to an Issue applies them once they exist.
Can I use this on multiple repos?
Yes. Point the webhook at every repo you want covered. The agent reads the repo and PR number from the webhook payload, so the same workflow handles all of them.

Stop reading every PR cold.

Connect GitHub and Slack once, and Geni triages every new pull request the moment it opens.