2,050 live links make a catalog, not a bot runtime
awesome-grokbot indexes 2,050 public Grok Bot configurations across eight categories, including coding, research, finance, publishing, and personal administration. Each row points to a canonical x.ai share page. The browser site adds search, category filters, English and Chinese text, and URLs that preserve the active filter. The same data is available in catalog.json under CC0, with a JSON schema for people building their own view or analysis.
That focus keeps the repository small. Our lab checkout at commit f10a82a was 4.5 MB, with 54 files and roughly 2,406 lines of source. The project contains a static site, generated category pages, catalog data, and Python maintenance scripts. It does not contain the listed bots or an agent runtime. If you clone it expecting a local Grok replacement, you have picked up the card catalog while the books still live at x.ai.
Daily link checks establish reachability only
A scheduled job runs at 05:17 UTC, merges four upstream catalogs, fetches each share page, rebuilds the English and Chinese pages, validates the result, and commits only when those checks pass. Its link checker separates dead pages from temporary server failures and request blocking. A 404 or 410 can retire an entry. A timeout, 5xx response, rate limit, or challenge page leaves the row in place. If blocked or flaky responses exceed 25 percent of a sweep, a circuit breaker refuses to rewrite the catalog.
The repository had 3 CI workflow files in our lab snapshot. They cover the daily catalog update, linting, and GitHub Pages deployment. This is careful plumbing for a list, especially because the method document explains why a single failed request should not erase a share. The limit is just as clear: link checks measure whether a page answered. They do not run a bot, inspect its later behavior, or prove that its description remains accurate after import.
What happened when we ran it
Our sandbox installed commit f10a82a in 7 seconds. The install added 35 packages and occupied 37 MB, then the build completed in 1 second. The run used an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Nothing in the supplied install or build result failed, which makes local inspection cheap even if your main interest is the JSON rather than the hosted site.
There was no test script or target, so our lab skipped tests instead of inventing a passing result. The checkout also had no tests directory and no Dockerfile. Pip-audit reported 0 known vulnerabilities among the installed Python packages. Those results describe one clean run of commit f10a82a. They do not measure the quality, safety, speed, or cost of any Grok Bot configuration linked from the catalog.
Every imported bot shares one cloud computer
The project’s strongest documentation may be its warning page. Every bot on one Grok account can reach the same cloud computer, including files, browser sessions, and logins. Adding a second bot does not create an isolation boundary. A share copies standing instructions, skills, routines, and first-party plugin IDs, while credentials stay behind and must be reconnected. The guide advises connecting one service at a time, checking the imported profile, and beginning with a read-only task.
That operational risk matters more than the repository’s 37 MB installed footprint. Some catalog entries can trade, send messages, drive a logged-in browser, or manage other bots. The maintainer has not imported and behavior-tested them. There is also no Dockerfile because this repository is a data set and static browser rather than a deployable bot service. Security review starts after you follow a link, precisely where the repository’s code ends.
A September 24 push matters more than the missing release
GitHub showed 319 stars, one open issue or pull request, and a last push on September 24, 2026. The only open item returned by the API was a pull request last updated September 6. No latest GitHub release exists. That release gap is worth recording, though it does not make the project stale: daily automated commits and a current catalog are better health signals for this kind of changing data set than a tag alone.
The project is young and still deserves a cautious maturity score. Our measured snapshot had 54 files, about 2,406 source lines, and three CI workflows, which is enough structure to make changes auditable without implying a long history. The method names source precedence, preserves old names as aliases, caps daily additions, and keeps dead links in a retired file. A public schema and generated pages also reduce the chance that one manual edit quietly breaks every view.
Use it for discovery, then audit the imported bot
awesome-grokbot earns a bookmark if you already use Grok Bot. Searching 2,050 entries by eight job categories is quicker than finding scattered X posts, and the source trail lets you see where a row came from. The project also states the uncomfortable part plainly: a green link means the share page loaded on a stated date. It says nothing about safety, maintenance, or whether the bot will do what its summary claims.
The 7-second install, 1-second build, and 0 known vulnerabilities make the repository itself an easy trial. The consequential decision comes later, when an imported bot asks for a connector or routine. Read its standing instructions, reconnect the minimum access it needs, and keep the first task read-only. If your policy requires tested behavior or isolation between agents, this catalog cannot supply either one.