Publish your eve agent to the evex registry
Add your agent to evex by pull request: scaffold with registry:new, fill in meta.docs, validate with the generator, and pass CODEOWNERS and review.
Scaffold a new agent
Agents join the catalog through pull requests to the evex repository. Start by scaffolding a complete package skeleton with your agent slug and GitHub username.
The slug becomes the public install name, @evex/{slug}, claimed first-come by the pull request that adds it. Pick a name that describes what the agent does, and treat it as permanent: renaming after merge breaks the install command for everyone who used it.
pnpm --filter @evex/agent-registry registry:new <slug> <github-username>Package layout
Each agent lives under registry/{slug} in the repository. The agent/ directory holds the eve source that installs into a consumer app; repo-only files such as package.json and tsconfig.json are never published.
- agent/ - the eve agent source installed into consumer projects
- evals/ - the eval suite, with evals.config.ts and one or more *.eval.ts files
- README.md - installed as the agent readme, so write it for the person running your agent
- .env.example - required whenever installed files read process.env, and it must declare every referenced variable with placeholder values
- registry.json - the manifest: name, title, description, author, categories, dependencies, the full file list, and meta.docs
Write meta.docs
registry.json carries a meta.docs block: the editorial documentation rendered on your agent page, covering the overview, how it works, use cases, requirements, and FAQs.
The scaffold seeds placeholder text. Replace every placeholder before opening the pull request, and bump meta.updatedAt whenever the docs change. Agent pages are how consumers evaluate your work, so treat this content as a first-class part of the package.
Validate locally
The generator validates registry.json against a Zod schema and regenerates the catalog artifacts. It enforces the contract mechanically: the declared file list must match the files on disk exactly, registry.json dependencies must stay in sync with package.json, .env.example must cover every environment variable the code reads, and every agent must pin the same eve version.
registry:scaffold generates registry.json from your package sources; review the result, especially categories, before validating. Run the full local pipeline before opening the pull request, since CI runs the same checks.
pnpm --filter @evex/agent-registry registry:scaffold <slug>pnpm --filter @evex/agent-registry generate
pnpm check && pnpm typecheck && pnpm testCODEOWNERS and review
Running generate also writes .github/CODEOWNERS, with one entry per agent owned by its registry.json author. Commit the CODEOWNERS update with your pull request; CI fails when the committed file is stale.
Automation covers schema shape, file and dependency sync, and environment coverage. Human reviewers focus on what machines cannot judge: that the author field matches your GitHub username, that the agent does what its README and description claim, that the declared dependencies are reasonable, and that .env.example contains placeholders rather than real credentials.