Hermes Atlas: A Static Directory With a RAG Chatbot Bolted On

The Gap Between a GitHub Search and a Usable Shortlist

Hermes Agent launched in February 2026, according to the README, and the repository's own framing is that a community of skills, plugins, integrations, deployment templates and forks appeared quickly. GitHub search does not answer the question an adopter actually has, which is which of these things are maintained and which are weekend experiments. Hermes Atlas positions itself as the canonical map, and the mechanism for that claim is a filter rather than a crawler. The contributing section lists five criteria: the project must be built for or integrated with Hermes Agent, must have been created after July 22, 2025, must not be a personal pet project or assignment, must show genuine effort, and must pass a basic security review. That last criterion is the one that separates the site from a topic page. The README states every project is security-reviewed before inclusion, and the repository layout includes a repos/ directory holding star count data, security review material and raw search results, so the review appears to leave an artefact rather than being an undocumented judgement call. The audience is narrow and clear: someone deciding whether to build on Hermes Agent who wants a starting shortlist instead of a search query.

No Framework, No Build Step, One HTML File

The frontend is vanilla HTML, CSS and JavaScript. The README is explicit that there is no framework and no build step, and the repository structure bears that out: index.html is described as the map and as a single-page application, and package.json carries only two dependencies, openai and redis. Those two dependencies exist for the serverless functions and the chunk builder, not for the page. This is a deliberate trade. A directory site with search, sort, filter, sparklines, trending badges and OS-preference theme detection is well within reach of plain JavaScript, and skipping a framework removes a toolchain from the maintenance surface. The cost is that index.html is doing a lot of work in one file, and any contributor who wants to add a view is editing that file rather than adding a component. For a project of this scope that is a reasonable call; it would not survive a second interactive surface.

How Star Data Flows From GitHub GraphQL to a Sparkline

The data path is the part of the architecture that is actually load-bearing. Three serverless functions sit behind the static page: api/stars.js fetches GitHub star counts and writes them to Redis, api/stars-history.js serves 30 days of history for the sparklines, and api/chat.js runs the retrieval pipeline. lib/redis.js is a shared client helper, so the cache connection is not duplicated across functions. The README states star counts carry a one-hour TTL and that daily history snapshots are stored separately, which is what makes the sparklines possible without keeping a database. GitHub is queried through GraphQL rather than the REST API. The GITHUB_TOKEN variable is documented as a fine-grained personal access token with public-repo read scope, and the README quantifies the reason to set it: 5000 requests per hour with the token against 60 per hour without. That is a real constraint, not a formality. Without the token the hourly refresh across the catalog would exhaust the anonymous limit almost immediately, so a deployment that skips this variable will show stale or missing counts rather than an error the visitor can interpret.

The Chatbot Is the Only Part That Needs a Build Step

Ask the Atlas is a retrieval-augmented chatbot grounded in 27 research files, and it is the reason the repository has a scripts/ directory at all. scripts/build-chunks.js splits the research/ directory into chunks and embeds them, writing data/chunks-meta.json for the chunk text and metadata and data/embeddings.bin for the vectors, which the README describes as float32 and roughly 14MB. Embeddings come from OpenAI's text-embedding-3-small and are computed once at build time, then served as static JSON, so no embedding call happens at query time. Retrieval is described as hybrid BM25 plus cosine similarity with MMR re-ranking and conversation-aware query rewriting, and generation goes through OpenRouter with a fallback chain. The README's stack list names Gemma 4 31B, then Gemma 4 26B, then Gemini 3 Flash, while the environment variable table gives the primary model default as deepseek/deepseek-v4-flash and the fallback default as google/gemini-3-flash-preview and google/gemini-3.1-flash-lite-preview. Those two lists do not match. Treat the environment variable table as authoritative, since it is the one that describes what the code reads, and treat the stack diagram as a sketch. OPENROUTER_MODEL and OPENROUTER_FALLBACK_MODELS both exist as overrides, so the model choice is configuration rather than a hardcoded decision, which is the right shape for a project whose underlying models will change.

Running It Locally Gets You the Page and the Pipeline, Not the API

The local workflow is short. Clone the repository, cd into it, run npm install, and the README notes that the install is only needed for the API endpoints and the chunk builder. To rebuild the knowledge base after editing anything in research/, the command is OPENROUTER_API_KEY=sk-or-... node scripts/build-chunks.js. To exercise the retrieval pipeline there is OPENROUTER_API_KEY=sk-or-... node scripts/test-rag.js, which the README describes as local RAG quality tests with 27 of 27 passing. That is the project's own reported figure from its own test script, not an independent measurement. For the page itself, the instruction is to open index.html in a browser, with the caveat that the API endpoints only work once deployed to Vercel. That caveat is the honest limit of local development here: you can read the map and rebuild the embeddings offline, but you cannot reproduce the star-count or chat behaviour without deploying or standing up equivalents of the three functions. The five environment variables to set on Vercel are GITHUB_TOKEN, OPENROUTER_API_KEY, REDIS_URL, and optionally OPENROUTER_MODEL and OPENROUTER_FALLBACK_MODELS. Only the token is marked as not strictly required, and as noted above, omitting it changes what the site can display.

Where the Curation Filter Becomes the Weakness

The same filter that makes the catalog useful also bounds it. The July 22, 2025 creation-date rule is measured against the Hermes repository creation date, so any integration that predates the agent and was later adapted is excluded by construction, regardless of how well it works. The exclusion of personal projects and assignments is a judgement call with no stated appeal process beyond opening an issue with a GitHub URL. And a security review performed at inclusion time is a snapshot: the README does not describe any re-review cadence, so a repository that passed when it was listed carries no ongoing guarantee. The static architecture has its own failure mode. Because the page is a single HTML file with no build step, there is no content pipeline that would surface a listed repository going dormant. The star sparklines will show a flat line, but nothing in the described system removes the entry or flags it. The catalog's accuracy depends on someone noticing. If what you need is completeness or continuous vetting, this is the wrong tool: a plain GitHub topic search with your own review process would cover more ground, less conveniently.

Against a Hand-Rolled List or a Framework Directory

The obvious alternative is a maintained markdown list, and the project already ships one: ECOSYSTEM.md is described as the markdown version of the map. That difference matters more than it sounds. A markdown list is trivially forkable and reviewable in a pull request, but its star counts go stale the moment they are written, and it has no search or trending signal. Hermes Atlas trades that portability for live data and a query interface. The second alternative is a general directory built on a framework, which would give you component structure, routing and a build pipeline. Hermes Atlas deliberately declines all three, which keeps the deployment to static files plus three functions but pushes complexity into index.html and into the caching layer. The choice is coherent: the value here is the curated data and the retrieval pipeline, not the presentation layer, and the presentation layer is the part that was kept cheap.

Licensing, Maintenance and What a Fork Inherits

The README splits the licence: site code under MIT, research content under CC BY 4.0, and repository descriptions and metadata sourced from the upstream projects' own documentation. That third category is the one to think about before republishing, because it means the catalog's descriptive text is not the project's to license in the first place. The repository metadata supplied here lists the licence as unknown, which is worth resolving by reading the LICENSE files rather than the README summary. The maintenance surface is small by design: two npm dependencies, no build step for the site, and a daily cron configured in vercel.json for the history snapshots. The recurring costs are the ones tied to external services, which are Redis Cloud for cache and history, OpenRouter for generation, and OpenAI for embeddings. Embeddings are computed once at build time and cached as static JSON, so that cost recurs only when research/ changes. Generation cost scales with chatbot usage, and the fallback chain exists precisely so that an unavailable primary model does not take the feature down. A fork inherits all of this: the same three accounts, the same five environment variables, and the same obligation to re-run build-chunks.js whenever the research files move.

Editorial conclusion

Adopt Hermes Atlas if you are evaluating Hermes Agent and want one page that lists ecosystem projects with a stated inclusion filter, rather than scraping GitHub search results yourself. Do not adopt it if you need an exhaustive index: the README states the catalog is quality-filtered, and the contributing rules exclude anything created before July 22, 2025, so early or tangential work will not appear. Before relying on it, check three things in the repository: whether data/repos.json has been updated since the last Vercel cron run, whether the licence field (which the repository metadata does not resolve) has been filled in, and whether the research/ directory still contains the 27 files the chatbot's answers are grounded in. If those three hold, the site is a usable reference; if repos.json has gone quiet, the live star counts are the only thing still moving.

Official sources

1. Issues
2. ksimback/hermes-ecosystem on GitHub
3. Project website
4. README