Shadcn registry for agents: installing workflows as source files
How the shadcn registry model applies to AI agent workflows, where users need source files rather than opaque packages.
A reusable agent is not just a dependency
Traditional packages work well when the user wants stable behavior behind an import. Agent workflows often need the opposite. The user wants to see the prompt, adjust the tool, change the channel, remove an integration, or add a stricter approval step.
A registry item can install editable files directly into the project. The user owns the result and can change it before running the agent.
This is the same reason shadcn became popular for UI: teams wanted useful starting points without surrendering ownership. Agent workflows have an even stronger version of that need because prompts and tools encode policy, tone, and authority.
What the registry must show before install
Before install, the registry should show files, target paths, dependencies, author, category, update date, and install command. Otherwise the user cannot answer the basic question: what will this add to my project?
This is especially important for agents because installed files can contain authority: tools that write to APIs, channels that receive webhooks, schedules that run unattended, and skills that shape judgment.
A previewable registry item reduces anxiety. The user can see whether the agent adds a Slack channel, a GitHub tool, a schedule, an MCP connection, or only local instructions. That makes the install feel like code review, not blind trust.
Why it pairs well with Eve
Eve already organizes agents as files under `agent/`. A shadcn registry item can place those files into the expected locations, while the user keeps ownership of the result.
The registry installs the agent files users need to review: instructions, tools, skills, channels, env examples, and evals.
For example, an Eve registry item can install `agent/instructions.md`, `agent/tools/`, `agent/skills/`, `agent/channels/`, `.env.example`, and evals together. Each file lands where an Eve developer expects it.
When not to use a registry item
Do not use a registry item for every reusable thing. Stable library code still belongs in a package. Small snippets may belong in docs. A registry item is strongest when several files work together and the user benefits from owning them.
The test is simple: if the user will need to inspect and adapt the files, a registry item is a good fit. If the user only needs to call a stable API, a package is probably cleaner.
Decision table
Shadcn registry item
Use when
Users should own, inspect, and modify the installed agent files.
Avoid when
The artifact is a stable library better consumed as a normal package.
npm package
Use when
The behavior is reusable code with a stable API and little need for local editing.
Avoid when
Prompts, tools, env files, and workflow policy need project ownership.
Docs snippet
Use when
The setup is tiny and educational.
Avoid when
The workflow has enough files that copy-paste becomes unreliable.
FAQ
Why not publish every agent as an npm package?
Because users often need to inspect and change prompts, tools, schedules, and channel behavior.
What makes a registry item good?
A clear job, explicit target paths, dependency declarations, setup docs, and files that belong together.
Is customization expected?
Yes. The registry gives users a reviewed starting point, not a permanent black box.