The registry is the artefact, and the npm package is private

A private package whose deliverable is a directory of files

The positioning is one line in the repository description: shadcn/ui, but for building agents.

That analogy explains the whole distribution model. In shadcn/ui you do not install a component package; a CLI copies component source into your project and you own it from then on. agentcn describes itself as using the same registry format and the same CLI.

Two files in the repository confirm that. There is a `components.json` at the root, which is the shadcn CLI's configuration file, and a `registry/` directory that holds what the CLI serves. The compatibility claim is structural rather than aspirational.

The `package.json` then does something that looks contradictory at first glance:

"name": "agentcn",
"version": "0.1.0",
"private": true,

The package is private and will never be published to a registry. Nobody installs agentcn as a dependency, because the thing being distributed is source that lands in someone else's repository. The version number exists to track the recipes, not to resolve an install.

The CLI is a development dependency at 4.5.0, which is the repository dogfooding the same tool its users will run.

registry:build runs before next build, and it strips types with Node

The build script is the clearest statement of how the pieces fit:

"build": "pnpm registry:build && next build",
"registry:build": "node --experimental-strip-types scripts/build-registry.mts",

The registry is generated first, then the site is built. Anything the docs page displays about available recipes has to exist before the site compiles, which means the registry is the source and the documentation is downstream of it.

The second line is the interesting one. The registry builder is a TypeScript file with an `.mts` extension, run directly by Node with type stripping rather than compiled first. The repository carries a second `tsconfig.scripts.json` alongside its main `tsconfig.json`, which is the usual way to type scripts differently from application code, and the `typecheck` script runs `tsc --noEmit` without emitting.

So there is no bundler step for the scripts, and no build output directory for them. Node does the work.

One more script deserves attention. `postinstall` runs `fumadocs-mdx`, which means a plain install of this repository's dependencies generates MDX as a side effect. For a documentation site whose content is MDX that is reasonable, and it is also the kind of thing that surprises someone who expected an install to do nothing but resolve packages.

Three frameworks are targeted and four are showcased

The README names three agent frameworks agentcn is built on: Eve, which is Vercel's, Flue, and Mastra. The corresponding feature bullet describes them as Eve, Flue and Mastra powered, with full access to powerful agent frameworks.

Then the section of curated community lists names four collections: awesome-eve-agents, awesome-flue-agents, awesome-mastra-agents, and awesome-langgraph-agents.

LangGraph is the odd one out. It is the only ecosystem in the showcase that is not one of the three the recipes are built on, so a reader arriving from a LangGraph background will find a curated list pointed at but no statement about which frameworks the recipes themselves target.

That gap is worth resolving in the documentation rather than leaving it to the reader. All four lists live in the same organisation and follow the same pattern, so the fourth may simply have been added for discoverability, but nothing in the text says so.

The hosting is split in two as well, which is minor but real. The homepage field points at agentcn.run, while every documentation link in the README points at agentcn.vercel.app, including the get started, installation and agents pages and the sponsor page.

The output is a terminal UI, and the docs page runs it live

Two feature bullets describe what you get and they sit oddly together.

The composable bullet says you build complex terminal UIs with simple, declarative components. So the artefacts are terminal interfaces, not web dashboards.

The live previews bullet says you can run each agent right from its docs page.

Put together, that is a documentation site which executes the thing it documents. The site is a Next.js application with Fumadocs handling content and MDX, and each recipe page is expected to be live rather than a code sample you copy.

That is a strong demonstration strategy for a registry of agents, because the failure mode of an agent recipe is usually invisible from source. Whether a tool call resolves, whether the instructions sequence correctly, whether a workflow terminates: none of that shows up in a code block.

It also means the docs site carries the runtime cost of every preview, and the `scripts` entry in `package.json` shows a script directory distinct from the app, with its own tsconfig.

The dependency list supports the reading. `cmdk` is a command palette library, `radix-ui` and `vaul` are primitives, `sonner` is a toast library, `motion` handles animation, and `react-hotkeys-hook` binds keys. That is the shape of an interactive terminal-style surface in React.

A recipe is instructions, tools, skills and workflows

The complete recipes bullet names what a recipe actually contains: full agent source in the form of instructions, tools, skills and workflows.

Instructions are the system prompt, tools are the callable surface, skills are the reference material an agent can load, and workflows are the orchestration. That is a fuller unit than a component, and it is the reason each recipe needs the agent framework it is built for rather than being framework-neutral source.

The word skills has a second meaning in this repository that is easy to miss. There is a `skills-lock.json` at the root, which is a lockfile in the agent-skills sense rather than the npm sense, pinning whatever skills the project consumes. Alongside it sit three directories whose names are agent tools: `.agents/`, `.claude/` and `.cursor/`.

Those three directories are the repository being dogfooded. A project that publishes agent recipes and also ships agent instructions for three assistants is making the point that its own development uses the same conventions it asks adopters to follow.

The rest of the root is conventional for a Next.js application: `app/`, `components/`, `lib/`, `hooks/`, `styles/`, `public/`, `content/`, `audio/` and a `seo/` directory, plus configuration files for Next, PostCSS and TypeScript. An `.env.local.example` is present, so the site expects some configuration even though the README advertises zero config.

The toolchain is Ultracite over oxlint and oxfmt, on Next 16 and React 19

The dependency versions place this project at the current edge of the ecosystem.

Next is pinned at 16.3.4 and React at 19.2.5, both exact. TypeScript is `^6.0.3`, shadcn is 4.5.0 and Ultracite is 7.6.1.

The linting and formatting story is the part with a point of view. There is no ESLint and no Prettier. Instead there is `oxlint.config.ts` and `oxfmt.config.ts`, with the `check` and `fix` scripts delegating to `ultracite check` and `ultracite fix`, and `lefthook.yml` plus a `prepare` script that installs the hooks. Ultracite is a wrapper over the Oxc tools, which are written in Rust, so the same repository runs a Rust-based linter and formatter.

One structural detail suggests the build is Next-aware beyond the app. There is a `proxy.ts` at the root rather than a middleware file, which is the convention that replaced middleware in recent Next versions.

The rest of the stack is a documentation toolchain: `fumadocs-core` and `fumadocs-mdx` for content, `shiki` and `rehype-pretty-code` for syntax highlighting, `mdx-components.tsx` and `source.config.ts` at the root. `ts-morph` is present as a runtime dependency, which is a TypeScript AST library and the kind of tool that reads components to generate documentation or a registry from source.

Maintenance is easy to date: the last push was on 2026-09-13, the licence is MIT, and the repository publishes no GitHub releases, so the recipes are versioned only by the private package version.

Editorial conclusion

Adopt agentcn if you want agent source you can read and edit in your own repository, since the shadcn registry model means a recipe becomes files you own rather than a version you pin. Do not adopt it expecting a library, because the package is marked private and the deliverable is the registry. Two things to check first: which of Eve, Flue and Mastra you already run, since the recipes are built on those three rather than on LangGraph, and whether you want a build step that strips TypeScript types with Node at registry-build time, which is what the pipeline depends on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. shadcn-labs/agentcn on GitHub