1 ---
2 name: github-solution-finder
3 description: Search GitHub for battle-tested open-source libraries and solutions
4 ---
5
6 # GitHub Solution Finder
7
8 Find battle-tested libraries instead of building from scratch. Use GitHub's search operators — they're far more precise than plain Google.
9
10 ## Search Operators (combine with spaces = AND)
11
12 | Operator | Example | Effect |
13 |---|---|---|
14 | `stars:>N` | `stars:>1000` | More than N stars |
15 | `stars:N..M` | `stars:100..500` | Between N and M |
16 | `language:X` | `language:python` | Primary language |
17 | `pushed:>DATE` | `pushed:>2025-06-01` | Commits after date — **the key freshness signal** |
18 | `created:>DATE` | `created:>2024-01-01` | Repo created after date |
19 | `topic:X` | `topic:cli` | Tagged with topic |
20 | `license:X` | `license:mit` | Specific license |
21 | `-X` | `-language:javascript` | Exclude (prefix any qualifier) |
22 | `archived:false` | | Exclude archived repos |
23 | `is:public fork:false` | | No forks |
24 | `in:name` / `in:readme` | `http in:name` | Restrict where term matches |
25 | `user:X` / `org:X` | `org:google` | Scope to owner |
26 | `"exact phrase"` | `"rate limiter"` | Phrase match |
27 | `NOT` | `redis NOT cache` | Exclude keyword (strings only) |
28
29 ## High-Signal Query Templates
30
31 ```text
32
33 # Baseline: established + actively maintained
34 <problem> language:<lang> stars:>500 pushed:>2025-06-01 archived:false
35
36 # Find the dominant library (only a few results = clear winner)
37 <problem> language:python stars:>5000
38
39 # Hidden gems (newer, not yet famous, but active)
40 <problem> language:go stars:50..500 pushed:>2025-09-01 fork:false
41
42 # Curated lists — these exist for almost every topic
43 awesome <topic> in:name stars:>1000
44
45 # CLI tools
46 <task> topic:cli stars:>200 pushed:>2025-01-01
47
48 # Commercial-safe only
49 <problem> license:mit OR license:apache-2.0 stars:>500
50
51 # Boolean grouping
52 (language:rust OR language:go) <problem> stars:>1000
53
54 # Code search (different syntax — searches file contents)
55 path:**/*.py "from fastapi import" symbol:RateLimiter
56
57 ```
58
59 ## Search Aggressively — webSearch Is Your Primary Tool
60
61 **Use webSearch extensively.** Do not rely on a single query or a single source. Every solution search should involve multiple rounds of web searching across different angles — GitHub, package registries, blog posts, Stack Overflow, and comparison articles. Cast a wide net before narrowing down.
62
63 ### GitHub searches
64
65 ```text
66 webSearch("site:github.com <problem> <language> stars")
67 webSearch("site:github.com awesome <topic>")
68 webSearch("site:github.com/issues <specific error message>")
69 webSearch("best <language> library for <problem> 2026")
70 ```
71
72 Note: GitHub-specific qualifiers like `language:`, `stars:>`, and `pushed:>` only work on GitHub's own search engine. Through `webSearch`, use natural-language equivalents (e.g. "python" instead of `language:python`). For precise filtering, use `gh search repos` if the GitHub CLI is available (see below).
73
74 ### Package registry searches
75
76 ```text
77 webSearch("site:pypi.org <problem>") # Python
78 webSearch("site:npmjs.com <problem>") # Node
79 webSearch("site:crates.io <problem>") # Rust
80 webSearch("site:pkg.go.dev <problem>") # Go
81 ```
82
83 ### Community and comparison searches
84
85 ```text
86 webSearch("<lib A> vs <lib B> <language>")
87 webSearch("<problem> <language> reddit")
88 webSearch("<problem> best library site:stackoverflow.com")
89 webSearch("<problem> comparison benchmark <language>")
90 webSearch("awesome <topic> list github")
91 ```
92
93 ### Read what you find
94
95 `webFetch` every promising repo URL to read the README directly. Don't just rely on search result snippets — actually read the README, check the examples, and look at the API surface before recommending anything. For comparison posts and blog articles, `webFetch` the full content to extract specific benchmarks and tradeoffs.
96
97 ## GitHub CLI (if available)
98
99 ```bash
100 gh search repos "rate limiter" --language=python --stars=">1000" \
101 --sort=stars --limit=10 --json=name,stargazersCount,pushedAt,url,description
102
103 gh api repos/OWNER/REPO --jq '{stars:.stargazers_count, pushed:.pushed_at, issues:.open_issues_count, license:.license.spdx_id, archived:.archived}'
104
105 ```
106
107 ## Health Evaluation — Check These Fast
108
109 | Signal | Healthy | Walk away |
110 |---|---|---|
111 | Last commit | <3 months | >18 months |
112 | Stars | >1000 (lib), >100 (niche) | <20 |
113 | Open/closed issue ratio | <0.3 | >1.0 with no replies |
114 | Contributors | 5+ | 1 (bus factor) |
115 | "Used by" (sidebar) | >1000 | 0 |
116 | Releases | Tagged, semver, changelog | No tags |
117 | License | MIT, Apache-2.0, BSD | None, GPL/AGPL (if commercial) |
118 | CI badge | Green | Missing or red |
119 | `archived: true` banner | — | Instant no |
120
121 **Red flags in issues:** Search the issue tracker for `"memory leak"`, `"abandoned"`, `"unmaintained"`, `"alternative"`. If maintainer hasn't replied to anything in 6 months, the project is effectively dead regardless of star count.
122
123 **Download trend check:**
124
125 - Python: `https://pypistats.org/packages/<name>` — declining = dying
126 - npm: `https://npmtrends.com/<pkg1>-vs-<pkg2>` — compare candidates head-to-head
127 - Check bundle size: `https://bundlephobia.com/package/<name>` (frontend only)
128
129 ## License TL;DR
130
131 | License | Commercial OK | Must open-source your code? |
132 |---|---|---|
133 | MIT, BSD, Apache-2.0, ISC | Yes | No |
134 | LGPL | Yes | Only if you modify the lib itself |
135 | GPL | Yes | **Yes, if you distribute** (viral) |
136 | AGPL | Yes | **Yes, even for SaaS** (network-viral) |
137 | No LICENSE file | **No** | default is all rights reserved |
138
139 ## Awesome Lists (curated entry points)
140
141 `sindresorhus/awesome` — the root of all awesome lists. Then: `awesome-python`, `awesome-go`, `awesome-rust`, `awesome-react`, `awesome-selfhosted`, `awesome-nodejs`, `free-for-dev`, `build-your-own-x` (learn by reimplementing), `public-apis`.
142
143 ## Comparison Output Template
144
145 ````markdown
146
147 ## pkg-name [12.4k stars, pushed 2 weeks ago, MIT]
148 github.com/owner/pkg-name
149
150 **Does:** One-line pitch.
151 **Fit:** Why it matches this specific problem.
152 **Install:** `pip install pkg-name`
153
154 **Pro:** Active, typed, 89% test coverage.
155 **Con:** Pulls in 23 transitive deps; async-only API.
156
157 ```python
158 from pkg import Thing
159 Thing().do(x) # minimal working example
160 ```
161
162 ````
163
164 ## Decision Rules
165
166 1. **Two libs within 2x stars of each other** → pick the one pushed more recently
167 2. **A lib with 50k stars but last commit 2023** → it's dead, find the fork (check "Forks" tab sorted by stars)
168 3. **Lib does 10x more than needed** → check if you can vendor the 200 lines you actually need (with attribution)
169 4. **Can't find anything with >100 stars** → problem may be too niche; search blog posts / Stack Overflow for how others solved it
170 5. **Found 3+ viable options** → npmtrends/pypistats comparison, then read the top 5 closed issues of each
171
172 ## Output
173
174 Always present key findings and recommendations as a plaintext summary in chat, even when also generating files. The user should be able to understand the results without opening any files.