// Use when building or changing an elizaOS-based application in this repository. Covers eliza app architecture, monorepo layout, local versus remote versus cloud routing, where to edit features, and non-negotiable runtime constraints. Eliza is the product name of this particular eliza app checkout.
Use when the task is building a new app on Eliza Cloud that earns money — chat apps, agent apps, MCP-backed tools, anything that calls the cloud's chat/messages/inference endpoints on behalf of users. Covers app registration, container deploy, markup configuration, affiliate header, and the survival-economics loop where earnings auto-fund the agent's own hosting. Pairs with the `eliza-cloud` skill (which covers Cloud as a backend in general) by focusing specifically on the build-and-monetize flow.
Use when the task involves Eliza Cloud or elizaOS Cloud as a managed backend, app platform, deployment target, billing layer, or monetization surface. The catch-all skill for any user request about THEIR existing apps / containers / earnings / credits / api-keys / analytics / billing — `list my apps`, `delete this app`, `change container size`, `what are my earnings`, `top up credits`, `regenerate api key`, `show analytics`. Covers app creation, `appId` usage, app auth flows, cloud-hosted APIs, analytics, credits, creator monetization, and custom Docker container deployments. For domain-specific ops defer to `eliza-cloud-buy-domain` / `eliza-cloud-manage-domain`.
Use when spawning a Claude Code, Codex, Gemini, Aider, or other CLI task agent whose work needs parent Eliza runtime context. Covers the read-only loopback bridge for character, room, memory, and active workspace state.
Use whenever a user wants to register or buy a custom domain for an Eliza Cloud app — including in the same request as building the app ("build me X and put it on Y.com"). Uses cloudflare as registrar, no human in the loop, paid from the user's existing cloud credit balance. Pairs with `build-monetized-app` (build first, then buy domain) and `eliza-cloud-manage-domain` (post-purchase: list, edit dns records, detach). Skip when the user is fine with the auto-assigned `*.apps.elizacloud.ai` subdomain.
Use after a domain has been purchased through Eliza Cloud (via the `eliza-cloud-buy-domain` skill) when the user wants to look at, edit, or remove a domain or its DNS records. Covers org-wide domain listing, per-app DNS record CRUD on cloudflare-managed zones, status re-sync, external-attachment verification, and detaching a domain from an app. Use this skill any time the user references domains they already own (`my domains`, `edit dns for myapp.com`, `delete that A record`, `is myapp.com still pointing at my app`).
Generate an energy-optimized, time-blocked daily plan
| name | eliza-app-development |
| description | Use when building or changing an elizaOS-based application in this repository. Covers eliza app architecture, monorepo layout, local versus remote versus cloud routing, where to edit features, and non-negotiable runtime constraints. Eliza is the product name of this particular eliza app checkout. |
This repository is an elizaOS application: a local-first assistant with CLI, dashboard, Electrobun desktop shell, connectors, and Eliza Cloud integration. Eliza is this app’s product and CLI name—not a separate platform from elizaOS.
references/repo-map.md for layout, edit targets, and common commandsreferences/runtime-and-cloud.md for runtime flow, onboarding, service routing, skills, and Eliza Cloud behaviorpackages/app-core/ for app shell behavior (API, CLI, onboarding, config).packages/agent/ for agent providers, services, and runtime glue around elizaOS.apps/app/ for UI and Electrobun work.eliza/cloud/ as the Eliza Cloud product and backend surface.eliza/ as upstream elizaOS. Edit it only when the bug or feature is genuinely upstream.NODE_PATH setup.bun install
bun run verify
bun run test
Narrower commands when useful:
bun run eliza ...
bun run dev
bun run dev:desktop
bun run test:e2e
packages/app-core/src/packages/agent/src/packages/app-core/src/onboarding/ and packages/app-core/src/runtime/@elizaos/skills, seeded into the state-dir skills folder by scripts/ensure-skills.mjseliza/cloud/ and the shipped eliza-cloud skillIf the task involves building an app and Eliza Cloud is enabled, linked, or explicitly requested, treat Cloud as the default managed backend before inventing custom auth, billing, analytics, or hosting. Use the eliza-cloud skill for app, monetization, and container details.
When the app clearly uses AI inference, treat it as a Cloud-backed monetized app
even if the user does not say "monetized", "OAuth", or "domain". Chatbots,
companions, assistants, generators, summarizers, and model-backed tools must use
Eliza Cloud app auth and /api/v1/apps/{id}/chat through the local app proxy.
Do not satisfy these requests with local canned responses. If the request is
ambiguous about whether AI/auth is needed, ask one concise clarification before
building.
elizaos — core runtime abstractions and upstream plugin patternseliza-cloud — apps, billing, monetization, auth, containers