Founders & Chiefs: Make GitHub Notifications One Tracked Task

This tool turns actionable GitHub notifications, assignments, mentions, review requests, and comments into prioritized tasks that sit next to your email, calendar, and meeting commitments. We rely on GitHub webhooks for near-real-time capture, with periodic reconciliation to catch anything a missed delivery lets slip. Every task keeps its source metadata and its identity as a pull request or an issue, so nothing gets flattened into generic noise.

TL;DR:

• Otto minimizes noise by filtering notifications to actionable reasons like assignments, mentions, and review requests, not all GitHub alerts.
• It preserves pull request identities by maintaining specific properties to prioritize stalled reviews over low-priority issues effectively.
• Connection setup should focus on minimal permissions and using webhooks with periodic reconciliation to avoid missed updates and reduce security risks.
• Deduplication relies on repository and issue or PR numbers to keep a single task per commitment, with tasks automatically closing when pull requests are merged or closed.
• Initial configuration should start narrow, focusing on key repositories and default presets, then expand once signal quality and priority settings are optimized.

Table of Contents

• How we model GitHub notifications and events as a single task record
• Setting up the connection: a practical checklist
• Keeping one task per commitment: priority and deduplication rules
• Permissions, security, and reliability in production
• Why this integration matters for how you start your day
• Bringing GitHub activity into your daily task list with Otto
• FAQ
• Sources

How we model GitHub notifications and events as a single task record

A GitHub notification carries two different layers of information, and we treat them as two different inputs to one task. The first layer is the notification thread itself, which includes a reason, such as assign, mention, review_requested, comment, team_mention, or state_change. GitHub’s notifications API documents these reason values, and we use them to explain, in plain language, why an item landed in your queue. The second layer is the canonical work item behind that notification, the actual issue or pull request, which carries the durable facts: title, number, repository, status.

We keep both layers because they answer different questions. The reason tells you why you’re being pinged right now. The underlying issue or PR tells you what the actual commitment is and whether it’s still open. Collapsing them into one undifferentiated “GitHub alert” is how most tools end up burying review requests under a pile of comment noise.

For every GitHub-sourced task, we capture:

• Source type: issue or pull request
• Repository and number: the canonical identifier
• Title and URL: for quick reference and one-click return to GitHub
• Requester: who asked for the review, assigned you, or mentioned you
• Reason: why this task exists right now
• Status and due date: open, in review, blocked, or done, with a next action

GitHub’s REST model represents every pull request as an issue with an added pull_request property, according to the Pulls API documentation. We preserve that property on the task record so pull requests never lose their identity among general issues, which matters for prioritization since a stalled review usually outranks a low-priority bug report. We also read the payload’s action field, documented in GitHub’s webhook events and payloads reference, to decide whether an event should create a new task, update an existing one, or close it out when a PR merges.

Setting up the connection: a practical checklist

Connecting GitHub to Otto is a short sequence of decisions, and the choices you make at each step determine how much signal versus noise you get afterward.

1. Authorize a GitHub App and scope repository access deliberately. Request the minimal permissions needed, generally read access to issues, pull requests, and notifications, rather than broad repo-wide write access. Narrower scope means less noise and a smaller blast radius if credentials are ever compromised.
2. Prefer webhooks over polling. GitHub’s own guidance recommends webhooks for notifying external systems of activity as it happens, which scales better than repeatedly polling the API. Subscribe to issue, pull_request, issue_comment, pull_request_review, and, where thread-level detail matters, pull_request_review_comment.
3. Map events to task types using sensible defaults. A review_requested event becomes a “review” task. An assign event becomes “task assigned to you.” A mention event becomes “you were mentioned, check for action needed.”
4. Set priority presets by role. A founder might want pull request reviews surfaced same-day and comment mentions batched for end of day. A chief of staff coordinating several teams might want anything tagged with a milestone escalated immediately, with everything else held for a daily digest.
5. Build in reconciliation. Webhooks occasionally miss a delivery during an outage or a misconfiguration. Running an occasional API check against the notifications endpoint and reconciling it with existing Otto tasks catches anything that slipped through, which the GitHub webhooks documentation explicitly frames as a backstop rather than the primary capture method.

Pro Tip: Start with a narrow repository list and the default mapping presets, then widen scope once you’ve confirmed the signal-to-noise ratio feels right for your week.

If you’re part of an engineering team building this kind of event-driven automation yourself, the patterns described in this piece on AI and web app automation cover similar webhook-driven design decisions worth considering before you wire up your own handlers.

Keeping one task per commitment: priority and deduplication rules

A single pull request can generate a dozen notifications before it merges: a review request, three comments, two re-review pings, a state change. Without deduplication, that becomes a dozen cluttered tasks instead of one tracked commitment with a clear next action.

We use the repository name plus issue or PR number as the canonical task ID. New notifications tied to that same number append to the existing task rather than spawning a duplicate, and checking the payload’s action field against an idempotency key prevents the same webhook delivery from creating the same task twice, a pattern GitHub’s webhook payload documentation supports directly through its action-specific event design.

Priority is set by a combination of signals:

• Reason weight: a review_requested or direct assign outranks a passive mention
• Requester identity: a request from a co-founder or direct report typically outranks one from an external contributor
• Repository importance: production repos outrank sandbox or documentation repos
• Labels and milestones: anything tied to an active milestone gets escalated

Comment and review events merge into the parent task instead of creating siblings. When a review thread grows long and clearly needs independent attention, for example a design debate buried in forty comments, we spin that off as a sub-task so it doesn’t block the parent PR’s own due date.

Pro Tip: Treat a merged or closed pull request as a trigger to auto-close its Otto task rather than leaving it to expire quietly on your list.

Permissions, security, and reliability in production

Connecting any external tool to your GitHub account is a trust decision, and we treat the permission surface as something you should be able to see and limit, not something buried in a settings page.

• Request minimum scopes. Limiting the GitHub App connection to specific repositories, rather than organization-wide access, reduces both risk and notification noise.
• Validate webhook signatures. Every payload should be checked against GitHub’s signature header over HTTPS, a pattern GitHub’s own tutorial on building a webhook-responsive app walks through directly.
• Rotate secrets periodically and build handlers that are idempotent, so a retried delivery during a network hiccup never creates a duplicate task.
• Keep an audit trail. Clear logs and an in-app explanation of what scopes were granted help a founder or chief of staff confirm exactly what an integration can see.
• Reconcile instead of over-polling. Use periodic reconciliation checks for missed webhook deliveries rather than frequent polling, which avoids unnecessary load against API rate limits.

Why this integration matters for how you start your day

The real value isn’t the task count. It’s that a review request sitting in GitHub no longer competes silently against an email thread or a meeting follow-up for your attention, it shows up in the same list, at the same priority scale. Expect an initial tuning period where you’ll mute a few noisy repos or adjust a reason’s priority weight before the signal settles. What matters most is that nothing gets sent or closed on your behalf without your sign-off. Otto drafts the task and the follow-up; you decide what happens next.

— Eddie

Bringing GitHub activity into your daily task list with Otto

We built Otto around one idea: your commitments shouldn’t live in five different inboxes. Email, calendar, meetings, and now GitHub activity all land in the same shared memory, so a pull request review and a promise you made on a call show up in the same prioritized list instead of five separate ones you have to mentally stitch together.

Getting started takes a few minutes:

• Sign up for a Free, Upgraded, or Max plan
• Connect your GitHub account and choose which repositories to include
• Turn on the default event mapping presets and adjust priority weights as needed

Every task Otto creates from a GitHub event is a draft of your next action, not an automatic reply or a closed loop. You approve what goes out and what gets marked done. If you want GitHub activity to stop living in a separate tab from the rest of your commitments, explore Otto’s plans and connect your account to see it in practice.

FAQ

Does Otto create a task for every GitHub notification?

No. Otto focuses on actionable reasons such as assign, mention, review_requested, and comment, rather than every notification GitHub generates. Low-signal events can be filtered out during setup so your task list reflects real commitments, not background noise.

How does Otto tell pull requests apart from regular issues?

GitHub represents every pull request as an issue with an added pull_request property, and Otto preserves that property when building the task record. That keeps PR-specific details, like review status and merge state, visible instead of flattening everything into one generic issue type.

What happens if a webhook delivery gets missed?

Webhooks are the primary capture method because they deliver activity as it happens rather than requiring constant polling. Otto backs that up with periodic reconciliation checks against the notifications API, so a missed delivery during an outage still gets caught and matched to the right task.

Can I limit which GitHub repositories Otto can see?

Yes, the GitHub App connection can be scoped to specific repositories rather than your entire account or organization, which keeps both risk and notification volume lower. We recommend starting narrow and expanding access only once the mapping and priority rules feel right for your workflow.

Does Otto ever comment or close things on GitHub automatically?

No action is sent or finalized without your explicit approval. Otto can suggest a next step, such as closing a stale task when a PR merges, but you confirm it before anything changes on GitHub’s side.