Looks cool. A few thoughts: - Why? Strongly suggest updating the README to explain why this is useful, or what kind of workflow makes this useful. Just a list

Looks cool. A few thoughts: - Why? Strongly suggest updating the README to explain why this is useful, or what kind of workflow makes this useful. Just a list of features isn't that compelling to me because I'm not sure I want it. - Because this is a gh cli extension, and not a standalone program, searching is unfortunately going to be fairly slow. There doesn't seem to be any local caching or syncing of the Github data. - Not really a user-impacting issue, just a fun fact: because the pagination is handled via Graphql's PageInfo support in their Graphql API, you'll never be able to page through more than 1000 results in a given response. - Authors might consider linking to https://docs.github.com/en/search-github/searching-on-github https://docs.github.com/en/search-github/searching-on-github in the README, it makes figuring out how to write a custom search a lot easier. - I'm happy to see XDG_CONFIG_HOME support, but the authors should consider also checking for a config file in $RepoRoot/.config/gh-dash/ and $RepoRoot/.gh-dash/, so that a single config could be more easily shared by members of a team who all check out the same repository. I'm working on something like this (customizable filter views for Github; quickly drill down into PRs by different authors, affecting different files, across multiple repos, filtered by regex search on the changed files / pr body / pr title / pr comments) but based in the browser, not a TUI. The primary goal of my project is to help engineering leaders understand what is actually getting shipped, and communicate that to other non-technical leaders. If anyone is interested in being a beta tester let me know, I'm hoping to have a release publicly available at the end of this week!