GitHub CLI extensions are useful, but extension discovery has a small practical problem: it is easy to find more extensions before you understand whether your current setup already covers the workflows you care about.
I built a small browser-only audit page for that problem:
https://sjh9714.github.io/gh-extension-atlas/audit.html?demo=1
It opens with a sample result loaded. If you want to check your own setup, run:
gh extension list
Then paste the output into the page.
The audit runs locally in the browser. There is no sign-in, no analytics script, and no remote audit API. The pasted extension list is not uploaded.
What the audit checks
The page compares installed GitHub CLI extensions against the GitHub CLI Extension Atlas catalog:
https://github.com/sjh9714/gh-extension-atlas
It shows:
- installed extensions that are already reviewed in the atlas
- installed extensions that are not listed yet
- missing Top Picks
- workflow coverage gaps
- copyable install commands for missing workflow recommendations
The goal is not to install every recommended extension. The goal is to make the next install decision smaller and easier to review.
Why not just use gh extension search?
gh extension search is useful when you already know what you are looking for.
It is less useful when the question is:
- Which terminal dashboard should I try first?
- Do I need a notification tool if I already use a broader dashboard?
- Which extension is for GitHub Actions operations versus workflow statistics?
- Is this branch cleanup tool the right fit for my risk tolerance?
Those are comparison questions, not search questions.
The atlas tries to answer them with a reviewed catalog, Top Picks, comparison guides, and workflow recommendations.
A few examples
For daily GitHub triage, the atlas points to gh-dash first because it covers PRs, issues, and notifications in one terminal dashboard.
For GitHub Actions, it separates different jobs:
-
gh-enhancefor an interactive Actions TUI -
gh-workflow-statsfor success rate and duration summaries -
gh-actfor local workflow runs -
gh-actions-importerfor migration work
For branch cleanup, it compares tools like gh-poi, gh-branch, gh-clean-branches, gh-tidy, and gh-worktree because they sound related but solve different habits and risk profiles.
The data contract
The catalog is also available as JSON:
https://sjh9714.github.io/gh-extension-atlas/api/extensions.json
Each entry includes fields such as:
- repository
- category
- install command
- best-fit use case
- avoid-if note
- license
- archived status
- maintenance status
- verification date
That makes it usable by scripts, documentation tools, or coding agents that need current extension metadata instead of stale memory.
What feedback would help
I am mainly looking for factual corrections and missing-extension suggestions:
- inaccurate descriptions
- wrong categories
- misleading maintenance labels
- better comparisons between overlapping tools
- useful GitHub CLI extensions that are missing from the catalog
If you maintain a GitHub CLI extension and the atlas describes it poorly, a short correction is enough.
Note: I used AI assistance while organizing the launch plan and editing this post, but the project metadata, examples, and claims were reviewed before publishing.
Top comments (1)
This is a good habit for CLI tooling in general. Extensions feel lightweight because they install through a familiar command, but they still run code inside a trusted developer environment.
I like auditing them the same way I would audit a small dependency: who maintains it, what permissions does it need, does it shell out, does it touch tokens or config, and can I remove it cleanly? Convenience tools deserve a little threat modeling too.