Your Repositories Need an Inbox

Once you maintain enough repositories, the problem is no longer opening one project. The problem is deciding which project deserves attention today.

One repository has an open pull request. Another has Dependabot alerts. A third has commits on its default branch that never became a release. Two exist on GitHub but are missing from the machine. Somewhere in that list is the thing you promised yourself you would look at last week.

GitHub has all the data. Your local checkouts have the rest. I wanted one queue.

maintainer turns those scattered signals into a terminal dashboard over every repository you can push to.

Start with signals, not a wall of repository names

On Apple Silicon macOS, install it with:

brew install AndrewDongminYoo/tap/maintainer
gh auth login

Then run:

maintainer

The list combines GitHub maintenance signals with local checkout state. It surfaces open pull requests, available Dependabot data, commits newer than the latest release, missing clones, the current branch, changed files, and the local ahead/behind count.

The last value carries an important footnote: it is measured against your last fetch. If you have not fetched in weeks, the tool says so instead of presenting stale local knowledge as remote truth. “Behind: 0” is comforting only when the remote-tracking data is current.

Filter the work you can act on

The dashboard can filter for repositories needing attention, vulnerability signals, or unreleased work. Activity sorting puts repositories with recent issue or pull-request conversations ahead of repositories that were merely pushed recently.

That choice matters. A busy discussion is usually asking for a human; a push is often just a push.

Select the rows you care about, then:

• o opens their local checkouts.
• c clones the selected repositories that are missing.
• g runs a configured claude or codex triage in each available checkout.
• p opens authored, assigned, and review-requested pull-request lists.

The tool does not review or merge a pull request. It gets you to the correct repository with the relevant maintenance signals visible. The judgment still belongs to you (sorry, the terminal has not accepted management responsibility).

A dashboard should also be scriptable

The same listing is available as JSON:

maintainer --json
maintainer --json --filter=vuln --sort=popular

That path is not a decorative export. The interactive UI needs a real terminal, while JSON makes the data layer usable from scripts and CI.

The project also treats uncertainty as data. When Dependabot alerts are unavailable, the row remains visible under the vulnerability filter with an unknown marker. An unavailable response is not silently converted into zero alerts. That would make the dashboard calmer and the maintainer less informed.

Open the morning queue, then leave

The original workflow was very specific: open everything that needs attention, start the relevant agent sessions, and then leave the house while the slow work begins.

That may not be your ritual. The underlying problem is probably familiar, though. Repository maintenance arrives as scattered signals across a browser, local directories, release pages, and half-remembered obligations.

Open maintainer when repository maintenance starts feeling like a memory test. The work remains yours; finding where it is hiding does not have to be.