Triage inbox for GitHub notifications

The idea

A Manifest V3 browser extension that sits on top of GitHub's existing /notifications page and turns it into a proper triage inbox. You get per-notification snooze (resurface in 4 hours, tomorrow, next week), batch selection with one-click dismiss or mark-done, and a rule editor that auto-archives notifications matching patterns you define — like "any PR from dependabot" or "any mention in a repo I no longer contribute to." No backend, no OAuth token, no account.

Why build this

GitHub's notification page is a read/unread list with almost no workflow support. You can mark things done and unsubscribe from threads — that's roughly it. Developers who manage open-source repos, contribute to several internal codebases, and run their own projects routinely sit on hundreds of unread notifications. The mobile app handles triage marginally better, but the desktop experience has barely changed in a decade.

Existing tools that attempt this (Octobox, Neat) are server-side apps requiring OAuth and a hosted backend, or they are abandoned. A pure-client browser extension with no backend dependency is the unoccupied position in the market. The whole value proposition fits in a content script and a service worker.

Stack sketch

• Extension runtime: Manifest V3, targeting Chrome/Edge first, then Firefox via the WebExtensions polyfill — the API surface needed is small enough that the overlap is nearly complete.
• Content script: injects a toolbar and per-row checkboxes into the /notifications DOM; reads notification metadata directly from GitHub's existing HTML rather than calling the REST API, so no token is required.
• Background service worker: manages snooze timers using chrome.alarms, which survive browser restarts. State lives in chrome.storage.local.
• Rule engine: a small JSON schema — {field: "author", op: "eq", value: "dependabot[bot]", action: "mark_done"} — evaluated against scraped row metadata when the page loads.
• No server: everything runs in the browser. Nothing leaves the machine.

Scope for v1

In: - Snooze any notification for 4 hours, 8 hours, tomorrow morning, or next Monday. - Checkbox multi-select rows, then batch mark-done or batch snooze. - Rule editor with 4–5 pre-loaded templates (bot authors, specific repos, review-requested-only, mentions). - Extension icon badge showing how many snoozed items resurface today. - Works exclusively on github.com/notifications — no inbox overlay or sidebar injection.

Out: - GitHub REST or GraphQL API integration. - OAuth or any server component. - Filters based on label, milestone, or team membership (all require API access; v2 territory). - Mobile browser support.

Where it could go

The obvious next step is an optional API mode: the user pastes a GitHub personal access token, and the extension switches from scraping the DOM to fetching notifications via REST. This unlocks metadata not visible on the page — label set, draft status, assignee — and makes rules far more powerful. It also makes the extension resilient to GitHub HTML redesigns, since the DOM is the main fragility of v1.

Beyond that, a focus-mode toggle that hides everything except notifications matching a saved filter would let developers timebox their GitHub triage: open GitHub twice a day, flip focus mode on, see only the items that matter right now.

Watch out for

GitHub's HTML structure is the single point of failure in v1: any redesign of the notifications page breaks all DOM scraping. Isolate every class name and data attribute lookup into a single constants file so a breakage is a 20-line fix. Also, GitHub's terms of service are permissive for personal-use extensions but grow murky around redistribution and monetization — read them before listing on the Chrome Web Store with a paid tier.