Event Automation

GitHub Issue Triage and PR Review on Trigger.dev

Durable Trigger.dev tasks behind a webhook gateway that auto-label new issues, review PRs, and post deploy summaries to Slack — each GitHub event routed to the right task with retries and full tracing.

What This Builds

This recipe builds a set of GitHub automations as durable background tasks: a new issue gets auto-labeled, a new PR gets an AI review, and a push/deploy gets summarized and posted to Slack. Each GitHub webhook event is routed to the matching Trigger.dev task, which runs with automatic retries, typed payloads, and a dashboard that traces every step.

The Hookdeck + Trigger.dev + Claude tutorial builds exactly these three Claude-powered automations and shows two routing patterns: a single router task that fans out to child tasks in code, and edge routing where separate webhook connections deliver each event type straight to its task.

Product Shape

This is event automation built on a durable runtime. The hard parts of webhooks — signature verification, retries, payload transforms, routing — are split out so your code is just application logic. Because tasks are durable, a slow LLM call or a transient GitHub API error doesn’t drop the event; it retries and traces.

The Stack

  • Trigger.dev — the durable task runtime: long-running TypeScript tasks with retries, queues, and run tracing.
  • A webhook edge such as Hookdeck — verifies GitHub’s HMAC signature, transforms the payload, and delivers to the Trigger.dev task trigger endpoint with a Bearer token.
  • GitHub repository — emits pull_request, issues, and push webhooks and receives labels, comments, and reviews.
  • A messaging surface (e.g. Slack) for deploy summaries.
  • A reasoning model such as Anthropic Startup Program credits to label, review, and summarize.

Step-by-Step Outline

  1. Write Trigger.dev tasks: triage-issue, review-pr, and summarize-push.
  2. Deploy the tasks; each exposes an authenticated trigger endpoint (POST /api/v1/tasks/{taskIdentifier}/trigger).
  3. Point a webhook gateway connection at GitHub; let it verify signatures and transform payloads.
  4. Start with a single router task that inspects the event and fans out to the right child task in code.
  5. Level up to edge routing: separate gateway connections with header filters deliver each event type straight to its task.
  6. In each task, call the LLM to label / review / summarize, then write back to GitHub or Slack; rely on built-in retries for reliability.

Why This Shape Works

Putting a verifying gateway in front of a durable task runtime removes an entire class of self-built infrastructure (an HTTP server that verifies HMAC, reshapes bodies, and forwards with auth). What is left is the part that matters: the agent logic. Durable retries mean GitHub events are never silently lost.

Source