| name | eve-agent-delivery |
| description | Deliver Eve agents end to end. Use when creating, modifying, testing, or deploying an Eve agent. |
Eve agent delivery
Agent-specific delivery procedure. Framework semantics live in
node_modules/eve/docs/ — load the eve skill and read the bundled docs before
using this skill. Do not restate Eve docs here.
Discovery
- Find the app root and package manager.
- Read
package.json, tsconfig.json, existing agent/ files, evals/, env
examples, Vercel config, and README setup notes. Done when you can list
every slot the change touches.
- Read
node_modules/eve/docs/README.md, then only the doc pages for those
slots. Done when you have identified the guide for each slot in scope.
- Identify required credentials, channel routes, webhook URLs, Vercel Connect
clients, model routing, route auth, and whether deploy should be preview or
production.
- Confirm local runs use a real sandbox backend. This agent uses Vercel Sandbox
with Node 24 so generated Eve apps can install dependencies, build, and run
evals.
- If local model-backed testing needs an AI Gateway credential and neither
AI_GATEWAY_API_KEY nor VERCEL_OIDC_TOKEN is present, use run_vercel_cli
action link_project after approval.
- Use the Vercel MCP connection through
connection_search for Vercel
inspection, deployment metadata, logs, Agent Runs, docs, and protected URL
fetches when those tools cover the task.
Implementation
- Keep the authored surface small. Add only the files needed for the requested
behavior.
- Put long operating procedures in skills so the base prompt stays readable.
- Put deterministic side effects behind tools. Use approval for external,
irreversible, user-visible, or production-impacting actions.
- Keep runtime helpers in
agent/lib/; only skills and sandbox seed files reach
the sandbox workspace.
- Declare every environment variable in
.env.example or the app's existing env
documentation.
- Use
run_eve_cli for Eve CLI operations. Use run_vercel_cli for Vercel
Connect setup, linking, and deploys. Do not route those through ordinary shell
commands.
- Prefer the Vercel MCP connection for read-only project/deployment/log work.
Keep Vercel CLI for local
vercel link and Connect commands that MCP does
not expose.
- For channels, follow channel-setup.
Parallel work
For independent subtasks — reading several doc pages, summarizing channel
setup options, running unrelated read-only checks — fan out with the built-in
agent tool: one call per subtask, all in one response, each message
self-contained (the child does not see this conversation). Children share the
workspace filesystem, so give parallel children non-overlapping write scopes
and keep file edits in the parent when in doubt. Approval-gated tools stay
gated inside children.
Testing
Follow testing-sequence.
Vercel deployment
Read node_modules/eve/docs/guides/deployment.md for build, env, sandbox,
auth, deploy, and verify. Before deploying, confirm the target project or team,
preview vs production, model credentials, channel webhooks, and route auth.
run_vercel_cli uses input-aware approval. whoami is read-only and runs
without approval. Before calling Vercel Connect setup, project linking, preview
deploy, or production deploy actions, state the exact operation and target. The
tool brokers app-runtime VERCEL_TOKEN through Eve's sandbox network policy, so
do not write Vercel tokens into generated source, command arguments, or sandbox
files.
Use run_vercel_cli for preview or production deploys. After deployment, verify
per channel-setup and the deployment doc.
Final report
Return:
- what changed
- tests and commands with pass or fail status
- deployment URL and Vercel target
- live verification evidence
- missing credentials or manual setup that blocked any step
