agentcn: a shadcn-style registry for agent source code
shadcn/ui, but for building agents. 🤖
At a glance
- What is it?
- agentcn packages complete AI agent recipes (instructions, tools, skills, workflows) in the shadcn registry format and installs them with the shadcn CLI. The README promises zero config and one-command setup, but the README is also nearly all the documentation you get from the repository itself.
- Who is it for?
- Adopt agentcn if you already run the shadcn CLI and want agent source you can read and edit rather than a framework you must learn from scratch; skip it if you need a documented, versioned release with a changelog, since the repository lists no releases.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap agentcn is aiming at: agent code with no distribution story
Most agent frameworks ship a runtime and a set of primitives, and leave the actual agent (its instructions, its tools, its skills, its workflows) for you to write. That is a lot of undifferentiated work. The prompts, the tool schemas, the retry behaviour, the file layout: every team rebuilds it, and none of it is reusable across projects because there is no shared packaging convention.
agentcn's answer is to borrow the convention that already worked for UI components. shadcn/ui did not publish a component library you install as a dependency. It published a registry you copy from, so the code lands in your repository and you own it. The README describes agentcn as "shadcn/ui, but for building agents" and says it uses "the same registry format and CLI". The unit of distribution is therefore not a package but a recipe: the README calls them "complete recipes" containing "instructions, tools, skills, and workflows".
The audience is narrow and identifiable. You need to be a TypeScript developer, comfortable with the shadcn CLI, and willing to work inside one of Eve, Flue or Mastra. If you have never touched any of those three, agentcn does not remove that requirement; it only removes the blank-page problem on top of it.
What actually gets copied: recipes, not a runtime
The distinction matters more than the marketing line suggests. agentcn is not an agent runtime. It does not execute anything on its own. The README lists Eve, Flue and Mastra as the frameworks the recipes are "built on", and describes the feature as "Eve, Flue, and Mastra powered" with "full access to powerful agent frameworks". So the architecture is layered: the framework supplies the execution model (model calls, tool invocation, state), and agentcn supplies the source files that configure that model for a specific job.
That means an agentcn recipe is closer to a project template than to a library. Once copied, it is your code. You can change the instructions, swap a tool, delete a skill. Nothing in the README suggests a mechanism for pulling upstream fixes back into a recipe you have already installed, which is the same trade-off shadcn/ui makes and the same one you should expect here.
The README also mentions "Live previews" where you can "run each agent right from its docs page". That is the one place the project touches execution, and it is a documentation-site feature rather than something in your repository.
Installation: what the repository actually tells you
This is where the material runs out. The README links to a Get Started page at agentcn.vercel.app/docs and an Installation page at agentcn.vercel.app/docs/installation, and states that setup is "One command setup" and "Zero config", with defaults described as sensible. It does not reproduce the command in the README body. The homepage field on the repository points to agentcn.run, while the README's own links point at the vercel.app deployment, so there are two hostnames in play and you should confirm which one is canonical before following a tutorial.
What can be said with confidence is the shape of the workflow, because the README states it explicitly: agentcn "works seamlessly with shadcn CLI" and is "shadcn/ui compatible" using "the same registry format and CLI". If you have installed a shadcn component before, the mental model transfers directly: point the CLI at a registry, name the item, and the files are written into your project. The specific registry URL, the item names and any config keys are not in the supplied material, so treat the docs installation page as the source of truth and read it before running anything.
One practical caution that follows from the shadcn model rather than from agentcn specifically: registry installs write files into your tree. Know which directory the recipe targets and whether it will collide with existing files before you confirm the prompt.
The three-framework bet and what it costs you
Supporting Eve, Flue and Mastra is the most interesting design decision in the project and also the one most likely to cause friction. A recipe has to be written against one framework's conventions. The README does not say whether a given recipe exists in three variants, whether recipes are framework-specific and labelled as such, or whether there is an abstraction layer that normalises the three. Based on the repository layout described, the first explanation is the most likely, but the material does not confirm it.
For an adopter this is the first question to answer. If you are on Mastra and the recipe you want is written for Eve, the copy is not free: you are porting tool definitions and workflow wiring by hand. The topics list on the repository includes all three framework names plus "agents", "shadcn" and "typescript", which is consistent with parallel support rather than a single unified layer, but it is not proof.
The upside of the same decision is that agentcn is not asking you to abandon your framework. It sits on top of whichever one you already chose. That is a meaningfully lower commitment than adopting a new agent runtime, and it is the strongest argument for trying a recipe before writing your own.
Where agentcn is the wrong choice
The repository lists no releases. That is a concrete fact from the metadata, and it has consequences. There is no version number to pin, no changelog to read, and no way to reason about what changed between the recipe you installed last month and the one on the registry today. For a solo developer prototyping, that is fine. For a team that needs to explain to an auditor which agent instructions were running in production on a given date, copying unversioned files from a live registry is a weak foundation.
The second limitation is documentation depth. The README is a landing page: features, showcase links, community, contributing, security, licence, sponsors. The substantive material lives on the docs site, which is not in the supplied material. If the docs pages are as thin as the README, you will be reading recipe source to understand what a recipe does, which is workable but not the "zero config" experience the tagline implies.
The third is the nature of copied code. Every recipe you install becomes a file you maintain. There is no dependency to bump. If the upstream recipe fixes a prompt-injection weakness in a tool, you will not be notified; you will have to notice. That is the price of the shadcn model, and it is real.
How this differs from installing an agent framework directly
The obvious alternative is to skip agentcn and start from Mastra, Eve or Flue on their own. Those projects ship the runtime, the model-provider integrations, the tool-calling loop and their own documentation. What they do not ship, generally, is a catalogue of finished agents you can drop in.
So the difference is not capability, it is starting point. With a framework alone you begin at an empty directory and write the agent. With agentcn you begin with a working agent and edit it. The second is faster for the first hour and identical in cost after that, because the code is yours either way.
A second alternative worth naming is the shadcn/ui registry ecosystem itself. If your project already pulls UI components through the shadcn CLI, agentcn adds no new tooling to your stack. That is the specific advantage of the compatibility claim, and it is the reason the project is positioned as it is rather than as a standalone CLI. If you are not already a shadcn CLI user, that advantage evaporates and you are simply learning a second tool.
Licence, maintenance and what to check before you commit
agentcn is MIT licensed, stated in the README and in the repository metadata. MIT is permissive: you can use, modify and redistribute the recipes, including commercially, provided the licence text and copyright notice travel with the code. Because recipes are copied into your repository rather than installed as a dependency, the notice obligation attaches to files now sitting in your tree, which is easy to overlook. This is a description of the licence, not legal advice; if the recipes end up in a distributed product, have someone check how you are attributing them.
The maintenance picture is mixed. The last push recorded on the repository is 2026-08-23, so the project is active. There is a CONTRIBUTING.md, a CODE_OF_CONDUCT.md and a SECURITY.md, plus GitHub Actions CI and a private vulnerability reporting path through GitHub Security Advisories. There is also a sponsor programme with a named gold sponsor. What is missing is the release history, and for a registry of copyable code that absence matters more than it would for a library.
Two practical checks come out of this. First, decide where recipes live in your repository and treat that directory as owned code with a reviewer, because nothing upstream will tell you when a recipe changes. Second, verify the framework mapping for the specific recipe you want before installing it, since the README does not state how Eve, Flue and Mastra variants are distinguished.
Editorial conclusion
Adopt agentcn if you already run the shadcn CLI and want agent source you can read and edit rather than a framework you must learn from scratch; skip it if you need a documented, versioned release with a changelog, since the repository lists no releases. Before committing, verify three things yourself: the exact install command on the docs installation page, which of Eve, Flue or Mastra each recipe targets, and whether the registry files land in a directory you are willing to own.
Community notes