Triage new GitHub issues automatically

Every issue that lands on your repo gets read, sorted, and summarized the moment it's opened — so you walk into a tidy triage instead of a wall of unread tickets.

• What you'll build — An app-event trigger on GitHub's New issue opened event that starts a short routine: read the issue, classify it (bug, feature, question, other), suggest labels, and send you a two-line summary with the link. Plus an optional weekly digest of everything opened that week. You build it all by chatting with your Personal Assistant.
• Who it's for — A maintainer, founder, or small team that wants incoming issues sorted without babysitting the repo.
• Time & plan — About 15 minutes. You'll need any plan that includes an agents budget, and you'll connect GitHub. Each triaged issue draws a little from your agents budget.

Start from the built-in template

The Personal Assistant's Tasks tab ships a GitHub issue triage starter (in the automation examples). Click it to open a Personal Assistant chat with the request pre-written — the walkthrough below is what follows. Or type it yourself.

Ingredients

#	You'll switch on	Where	Needed for
1	The Personal Assistant agent	Built in to the Agents section	Builds the routine and trigger for you
2	GitHub connector	Connect from the chat (one-click sign-in)	Watching your repository for new issues
3	One app-event trigger	The agent adds it for you	Firing the routine the instant an issue opens
4	A weekly schedule (optional)	The agent adds it for you	The Friday digest of the week's issues

Steps

1. Open the GitHub issue triage starter

Open Agents → open the Personal Assistant → Tasks tab, and click GitHub issue triage. It opens a chat with the request filled in:

Set up issue triage for my GitHub repository. When a new issue is opened, read it, classify it (bug, feature request, question, or other), suggest labels, and send me a two-line summary with the link…

Send it.

2. Answer the setup questions

Agent: Which repository should I watch — owner and repo name? And how do you want issues categorized: the standard bug / feature / question / other, or your own buckets?

You: acme/webapp. Standard buckets are fine, but add a "security" one.

A GitHub trigger watches one repository — you give it the owner (acme) and the repo (webapp). If you didn't say, the agent asks.

3. Connect GitHub right in the chat

If GitHub isn't connected yet, the assistant shows a connect card in the conversation:

Agent: Connect GitHub and I'll set the watch up.

Click Connect → GitHub's sign-in opens in a popup → approve. The card flips to connected and GitHub is switched on for this agent. Click Continue.

4. Let it create the trigger on the real event

The assistant checks GitHub's available events rather than guessing. GitHub exposes several — these fire instantly:

GitHub event	Fires when
New issue opened	An issue is opened in the watched repository
Pull request opened or closed	A PR is opened, closed, or gets new commits
New commit pushed	A commit is pushed
Repository starred	Someone stars the repo
Issue assigned to you	An issue is assigned to your account (checked periodically)

For triage, the one you want is New issue opened.

Agent: I'll watch acme/webapp for New issue opened (it's instant). Creating the trigger now.

The trigger goes live. From here, every new issue on that repo fires the routine.

5. Sample it on a real issue before trusting it

Don't wait for a real report — triage an existing one as a sample:

You: Run it once on issue #212 so I can see the format.

The routine reads the issue, classifies it, suggests labels, and produces the two-line summary:

🐛 Bug · suggested labels: bug, needs-repro #212 "Login redirect loops on Safari" — user hits an infinite redirect after SSO on Safari 17; no repro steps yet. → https://github.com/acme/webapp/issues/212

If you'd rather it were terser, or classified differently, say so — the assistant adjusts the routine and you re-sample. When it reads right, you're live.

Suggests labels — doesn't apply them

By design the routine suggests labels and writes you a summary; it doesn't change the issue. Reading and drafting run safely on their own. If you want it to actually apply labels or post a comment on the issue, that's a change to GitHub — an outside-world action that sits behind an approval gate, pausing each fire for your OK. Ask for it explicitly if you want it.

6. Watch it work

Each new issue now opens (or continues) the trigger's own conversation in your chats, where you can see everything it's triaged. Ask your assistant "what has my GitHub trigger done lately?" to see recent fires, anything skipped as a duplicate, and anything waiting.

Add the weekly digest (optional)

The template offers a companion: a weekly summary of everything opened that week. Just say:

You: Also give me a Friday 5pm digest of all issues opened this week, grouped by category.

The assistant attaches a weekly schedule (a cron like 0 17 * * 5) to a small digest routine. Now you get instant triage as issues arrive and a tidy weekly roundup — the two kinds of automation, side by side: a trigger for "the moment it happens" and a schedule for "on a clock."

Make it yours

• Only some issues. "Only issues labeled bug" or "skip anything opened by our own team" — filters are described in plain language, and events that don't match are skipped for free.
• Route by category. Add a step that, for a security-classed issue, pings you on Telegram or Slack immediately (a message step, so it carries an approval gate — or notify yourself only, which is fine unattended).
• Triage PRs too. Point a second trigger at Pull request opened or closed to get the same summary treatment on incoming PRs.
• Mind the limits. Up to 10 triggers per account; each fires at most 12 times an hour — a busy repo's overflow simply waits for the next hour. See Triggers → limits.

See also

• App-event triggers — the full GitHub event list and the rest of the catalog
• Triggers — the shared mechanics: the trigger's conversation, queueing, duplicates, limits
• Tasks & schedules — how the weekly-digest schedule runs
• Custom routines — how the multi-step routine is built, and when a step needs an approval gate
• Dev task-board manager — a broader agent that also updates your project board
• Usage & billing — how each triaged issue is metered