octoscope v0.15.0 — Notified when it matters 🔔
Two additions that close the loop between watching (what v0.14.0 widened) and noticing (what's actually waiting for your attention). One feature lands on screen, one in your macOS notification center; both keep octoscope read-only.
Review-requests inbox
The PRs tab now shows a sticky "PRs awaiting your review" section above your authored list — whenever someone has requested you as a reviewer. Same partition idiom as Repos pinned/watched (v0.13/v0.14): muted rule separator between segments, cursor walks both, sort cycle only re-orders the authored half (review-requests stay in GitHub's UPDATED_AT DESC order), filter applies to both.
Section is absent when count == 0 — no rule, no header, the tab looks identical to pre-v0.15.0 if no one's waiting on you. Discovery is via the README, not visual noise.
One GraphQL search call (review-requested:@me), gated on viewer mode (no point asking GitHub for someone else's inbox), running in parallel with the rest of the dashboard refresh. Drilling in opens the full PR detail (v0.11.0 surface with v0.12.0 syntax-highlighted diff viewer) with the requester's login visible.
macOS notification subtitle
Stars/followers change notifications now carry a second line — Stars, Followers, or Stars & Followers when both moved at once. Two wins:
- The Notification Center keeps per-entry timestamps visible even when terminal-notifier groups notifications. Without the subtitle, grouped notifications collapse and only the most recent shows when it arrived.
- The banner gains a visible category line under the title, useful when you spot the banner after the body has already scrolled past.
Upgrade
brew upgrade gfazioli/tap/octoscopeOr grab a binary from the release page: https://github.com/gfazioli/octoscope/releases/tag/v0.15.0
As always: read-only, free, MIT, on Linux / macOS / Windows. Source: https://github.com/gfazioli/octoscope
How do you split your day between "PRs you authored" and "PRs you're meant to review"?
Curious if anyone has a watch_repos config they curated specifically because they review for a team there.
Replies
Great additions! Answering your question: PRs I'm meant to review are coming into a manually compiled list, because quite often reviewers aren't added explicitly, given that there might be several people who can be looking into a specific set of changes, therefore there is a bit of process before deciding who is checking what - and this is usually taking a dedicated amount of time, up to 1.5h per day
octoscope
@sk_uxpin Thanks Stan! That’s a really useful data point — 1.5h/day just on the triage-before-the-review is significant, and it confirms something I suspected: the bottleneck often isn’t reading the diff, it’s figuring out which diffs are yours to read.
The current review-requests section in v0.15.0 only catches PRs where you’re explicitly added as a reviewer on GitHub, so it wouldn’t cover your scenario yet. But your workflow is interesting — a manually compiled list means you already have a mental model of “these repos/paths are mine to watch.” That’s close to how watch_repos works today for the dashboard itself.
Out of curiosity, is that manual list something you keep in a doc, or is it more of an informal team convention?
@gfazioli sorry, I didn't express myself correctly - I was referring to 1.5h per day for actual reviews. The manual triage is about 10-15 minutes per day, and the resulting list is just being compiled by the PM and announced to the team in a Slack channel
octoscope
@sk_uxpin Ah got it 😉 that makes more sense — 1.5h of actual review time is solid. And having the PM compile and post the list in Slack is a clean workflow. Thanks for clarifying! 👍
@gfazioli yeah, maybe not the ideal approach, but still works :)
Just discovered octoscope and really like the concept! I think we will soon never have to leave our terminals lol
I'd say 90% authoring my own, 10% reviewing; in the end it mostly depends on whether you're new to the team or not, you might need to do more reviewing if you're trying to get to know the codebase
octoscope
@georges99226084 Thanks Georges, glad you like the idea! And yes, the terminal takeover is real — I keep adding surfaces that used to live in a browser tab, so at some point the terminal is the browser 😄
That 90/10 split is interesting — and the point about reviewing more when you’re ramping up on a codebase rings true. That’s actually one of the reasons I added the review-requests section: when you’re in that “getting to know the code” phase, having those PRs surfaced right next to your own makes it easier to stay on top of both without context-switching to the GitHub UI.
Curious — do you work mostly on your own repos or contribute to team projects?