llms-txt-hub: a directory, a Next.js app, and an npm CLI for shipping llms.txt

The gap llms-txt-hub fills is discovery, not the format itself

The llms.txt file is a convention for telling LLM-powered tools how they should read a project's documentation and codebase. The format is not the hard part. Finding out who has actually published one is. The repository positions itself as a central hub for discovering and sharing llms.txt implementations across projects and platforms, and the README lists the outcomes it claims for the standard: guiding models on how to interpret documentation, standardising access for LLM tooling, improving answer accuracy, and setting boundaries for AI interaction with content. Those are the stated goals of the format, not measured results from this repository. The audience splits in two. Site owners who want their documentation readable by agents need somewhere to register the file. Developers who consume documentation through agents need a way to find files that already exist. The repository serves both by pairing a browsable directory with a set of client tools. The directory is organised into primary categories (AI & ML, Developer Tools, Data & Analytics, Integration & Automation, Infrastructure & Cloud, Security & Identity) and secondary categories such as personal, agency, e-commerce, education, media and international. The split matters because the entries are not all developer documentation. A Polish law firm, a CMMC compliance consultant and a Montréal B2B branding agency sit in the same list as infrastructure vendors, which tells you the directory is a registry of published files rather than a curated set of technical references.

What the web app is built on, and what the repository does not say

Topics on the repository name Next.js, Supabase, Supabase Auth and Tailwind CSS, and the primary language is TypeScript. From that you can infer the shape of the hosted site: a Next.js application rendering the directory, Supabase holding the listings and handling authentication, Tailwind for styling. What you cannot infer from the supplied material is the data model, how a new entry is submitted, whether submissions are moderated, or how the site refreshes its list. The README contains a generated block marked with an HTML comment reading "LLMS-LIST:START - Do not remove or modify this section", followed by the entries themselves in Markdown. That marker is the most concrete architectural detail available: the directory content is injected into the README between fixed boundaries, which is the usual pattern for a build step or a script that regenerates the file. The repository does not document that step, so anyone forking it should treat the marker as a contract to preserve rather than a feature to rely on. The same caution applies to the licence. The repository metadata reports NOASSERTION, which means GitHub could not match the licence file to a known identifier. If you intend to reuse the web app code, read the licence file in the repository before you copy anything, and treat that as a question for your own legal review rather than something this article can settle.

llmstxt-cli is the piece with a release history

The only releases listed are for llmstxt-cli: 0.3.0, 0.4.0 and 0.4.1, all dated 13 February 2026, with 0.4.1 published at 17:32 UTC. Two releases in the same day, hours apart, is a normal cadence for a young CLI and also a signal that the surface is still moving. The README describes the tool as installing llms.txt docs as skills into 35+ AI coding agents, and points to packages/cli/README.md for details. That path is the one to read before adopting, because the repository-level description gives the count but not the agent list, the install location per agent, or what happens on an agent that is not recognised. The topics list includes cursor and cursor-ai, so Cursor is at least part of the supported set. Beyond that, the material does not enumerate the agents. The distinction the description draws is worth pausing on: the CLI installs docs as skills, not merely as files. A skill is a unit an agent loads on demand, so the mechanism implies writing into an agent-specific directory in a format that agent expects, which is different from dropping a llms.txt at a site root. If your agents are configured through a shared repository path rather than per-user installs, verify where the CLI writes before you run it across a team.

Getting it running: the commands the material actually supports

The README links llmstxt-cli to its npm page and to packages/cli/README.md inside the repository. It does not print an install command, so the safest statement is that the package is distributed on npm under the name llmstxt-cli and that the CLI README is the authoritative source for invocation. Running a package directly with npx is the conventional way to try a published CLI without a global install, and the package name supports that form, but treat the exact flags as unverified until you read packages/cli/README.md. The same caution applies to the web app. The repository is a monorepo: the README references apps/web/public/img for the screenshot asset and packages/cli for the CLI, so apps/ and packages/ are the two workspace roots visible in the material. Building the site locally would mean installing dependencies at the repository root and running the Next.js app in apps/web, and it would require Supabase connection details that the README does not describe. There is no documented environment variable, no schema file and no migration command in the supplied text. If you want the directory data rather than the application, the README itself is the export: the generated block is plain Markdown with names, URLs and links to each site's llms.txt and, where present, llms-full.txt.

The llms-full.txt distinction and why it changes what you index

Entries in the directory carry one or two links. Some list only llms.txt. Others list llms.txt and llms-full.txt, for example the Montréal branding agency, the AI development company, the London and Warsaw web studio, the Indian attestation service and the Ruby on Rails consultancy. The two-file pattern is the interesting part of the listing format. A short llms.txt typically acts as an index of what a site wants a model to read, while llms-full.txt carries the expanded content. For a directory, that means an entry is not just a name and a URL: it advertises how much material the site is willing to hand to a model. The README does not explain the convention or state a size expectation for either file, so the distinction is visible only in the data. If you are building a crawler over this directory, that difference should drive your fetch strategy, because a site that publishes llms-full.txt is inviting a much larger read than one that publishes only the index. The directory also attaches a favicon for each entry, fetched through Google's favicon service at a fixed size, which is a rendering detail rather than a data one but does mean the list depends on an external service to look complete.

Where this is the wrong tool

A llms.txt file is a convention, not an enforced contract. Nothing in the material suggests any agent is obliged to fetch or honour one, and the directory cannot verify that a listed file is accurate, current or complete. The entries are self-published URLs. A site can publish llms.txt, appear in the hub, and still serve documentation that contradicts the file. If your requirement is that a model reads only approved content, this repository does not provide that guarantee at any layer. There is a second, narrower failure mode. The directory mixes marketing pages, professional services and developer documentation in one list. An agent pointed at the whole directory as a knowledge source would be reading a law firm's Polish-language service description alongside a cloud vendor's API index. The category structure exists to prevent that, but the README shows the categories as labels on a flat list, and it does not describe filtering, ranking or deduplication. The third limitation is maintenance. The only releases in the material are CLI versions from a single day in February 2026, while the repository's last push is dated 10 September 2026. That gap is consistent with a project whose directory updates continuously while the packaged tooling moves in bursts, which means the CLI you pin today may lag the agent ecosystem it targets.

Alternatives, and the actual difference in approach

The most direct alternative is not another directory but the file itself. A site owner can write llms.txt at the domain root and skip registration entirely, because discovery through this hub is optional. The trade-off is visibility: the hub is a place agents and developers might look, and a file on your own domain is only found by someone who already knows your domain. The second alternative is the set of single-purpose tools the README lists alongside the CLI. The LLMs.txt Checker is a Chrome extension that reports whether a site implements the file, which answers a yes-or-no question rather than installing anything. The VS Code extension and the Raycast extension both search and explore llms.txt files from inside their host application, so the document is read where you already work instead of being written into an agent's skill directory. The MCP Explorer takes a different route again, exposing llms.txt files through the Model Context Protocol so a compatible client can query them. The LLMs.txt Generator runs the process in reverse, producing a file from a sitemap or crawled pages. Choosing among these comes down to direction: generator for publishing, checker for auditing, extensions and MCP for reading on demand, llmstxt-cli for pushing documentation into agents ahead of time.

Maintenance cost and what to verify before you commit

For a consumer of the directory, the cost is close to zero. The README is Markdown, the entries are plain links, and you can parse the generated block without touching the application. For a site owner, the cost is the ongoing accuracy of the file you publish, because a stale llms.txt is worse than none if agents act on it. For anyone running the web app, the cost is a Next.js and Supabase deployment plus whatever process regenerates the LLMS-LIST block, and that process is not documented in the material. For llmstxt-cli, the cost is version tracking: 0.3.0, 0.4.0 and 0.4.1 landed within hours of each other, so pinning a version and reading the changelog between bumps is the realistic posture. On licensing, the repository metadata reports NOASSERTION, meaning no recognised licence identifier was detected. That is a fact about the metadata, not a statement about your rights. Read the licence file in the repository and the npm page for the CLI package, and confirm both with your own legal review before you redistribute either. Then run the CLI against one agent on one project and inspect the files it writes before you roll it out, because the repository page gives you a count of supported agents but not the list.

Editorial conclusion

Adopt llmstxt-cli if your team already runs several AI coding agents and wants one command to place a project's llms.txt where those agents look. Do not adopt it as a compliance or access-control layer: the directory entries are self-published URLs, and a llms.txt file is a convention that clients may ignore. Before relying on it, run npx llmstxt-cli against a single agent, confirm the files land where that agent actually reads them, and check the CLI package README for the current list of supported agents rather than trusting the 35+ figure on the repository page.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. thedaviddias/llms-txt-hub on GitHub