author-atom-eve-agent

Author an Atom Eve agent

Atom Eve is an open registry of installable AI agents, like shadcn but for agents. Authoring one means adding a folder under registry/<agent>/ in the elie222/atom-eve repo and opening a PR. This skill is the entry point; the full reference is the repo's AGENTS.md, and the README has its own skill, agent-readme.

Get into the repo

You author inside the repo, next to the example agents and the generator that validates them.

• Not in the repo yet: fork and clone it (gh repo fork elie222/atom-eve --clone, or clone your fork), then pnpm install.
• Already in it: work in registry/<agent>/.

Start from the closest existing agent (browse registry/) rather than a blank folder.

What earns being an agent

An agent must do work only an LLM can do: judgment, reasoning, writing. If removing the model leaves roughly the same output, it is a script, not an agent. Tools, CLIs, and connections return raw facts; the model does the reasoning and the writing. Never bake copy or decisions into tool code.

Do not publish a registry entry that is only a thin wrapper around a reusable skill. If the same result is better achieved by telling Claude Code or another coding agent to load the raw skill, keep it as a skill rather than an Atom Eve agent. The strongest shape is an unattended check-then-act loop: the agent checks real project state (merged PRs, live pages, connected data), verifies what it finds, and then acts — opens a PR, files issues, or alerts a channel only on material change (docs-sync is the model). Channel workflows that change where work happens, connected data sources, durable history, and guarded writes also count. A schedule or Slack access alone does not: a cron that re-runs a generic audit and emits a report is still a skill wrapper, and a prompt that says "use this skill/CLI and write a report" is not enough on its own.

The pattern (headlines; AGENTS.md has the detail)

• Structure. registry/<agent>/ holds exactly three things: README.md (manifest in its frontmatter, pitch in the body), SETUP.md (env/config facts in frontmatter, walkthrough in the body), and agent/ (instructions.md, which opens with a <!-- project-config --> block, plus optional connections/, schedules/, sandbox/, tools/, skills/, lib/). The build derives name, title, family, and connections. See "Anatomy of an Agent".
• Capability: walk the ladder, stop at the first rung that fits. Start by looking the service up on integrations.sh (GET https://integrations.sh/api/{domain}/surface, or its public MCP server https://integrations.sh/mcp) to see which surfaces exist and what auth they need; its credential guides also feed SETUP.md env entries (verify discovered facts against official docs). Then: 1) A good CLI exists: run it in the sandbox + a usage skill. 2) A hosted MCP server exists: MCP connection, narrowed with tools.allow. 3) A small known API surface: plain defineTool with a direct fetch, shared client code in agent/lib/. 4) Big API surface, no CLI, no MCP: OpenAPI connection, the last resort, narrowed with operations.allow. See "Giving an agent capability".
• Be opinionated. Wire every data source the agent needs and make them all required; name a primary (first-party ground truth) and a secondary (competitive / gap) rather than marking either optional. Only a stack-dependent write destination (a GitHub blog vs a CMS) is optional.
• Config in one place. What the operator sets (site, domain, repo, keywords) lives in the <!-- project-config --> block at the top of instructions.md, mirrored one-to-one by SETUP.md config; the schedule's prompt stays generic and refers to "the configured X".
• instructions.md is addressed to the agent in the second person. No credentials, no marketing tone, no "edit this after install".
• README: use the agent-readme skill. Value-led "What it does", skimmable, no Setup section. Everything the agent needs (env, config, the wiring walkthrough) goes in SETUP.md instead.