| 1 | --- |
| 2 | name: a0-development |
| 3 | description: Development guide for extending Agent Zero from current source and DOX. Use for framework architecture, tools, extensions, API/WebUI handlers, agent profiles, prompts, skills, projects, runtime boundaries, and contribution workflow. Load the focused reference files before giving implementation guidance. |
| 4 | version: 1.1.0 |
| 5 | author: Agent Zero Team |
| 6 | tags: ["development", "framework", "agent-zero", "extending", "tools", "extensions", "skills", "api", "agents", "prompts", "dox"] |
| 7 | trigger_patterns: |
| 8 | - "extend agent zero" |
| 9 | - "agent zero development" |
| 10 | - "build agent zero feature" |
| 11 | - "create agent zero tool" |
| 12 | - "add extension" |
| 13 | - "framework development" |
| 14 | - "agent zero architecture" |
| 15 | - "how does agent zero work" |
| 16 | - "create agent zero extension" |
| 17 | - "add api endpoint" |
| 18 | - "create agent profile" |
| 19 | - "agent zero internals" |
| 20 | - "how does the agent loop work" |
| 21 | - "extension hook points" |
| 22 | - "prompt system" |
| 23 | - "agent profile" |
| 24 | - "dox" |
| 25 | --- |
| 26 | |
| 27 | # Agent Zero Development |
| 28 | |
| 29 | Use this skill as the entry point for Agent Zero framework development. It is intentionally lean: load only the reference files that match the task, then verify against the current repository before changing code. |
| 30 | |
| 31 | ## Reality Rules |
| 32 | |
| 33 | 1. Source and nearest DOX beat memory, examples, and this skill if they disagree. |
| 34 | 2. Before editing, read the applicable `AGENTS.md` chain from the repo root to every file you expect to touch. |
| 35 | 3. New capabilities should usually be plugins. For plugin-specific work, load `a0-plugin-router` and follow the routed specialist skill. |
| 36 | 4. Do not assume ports. Discover WebUI host/port from startup output, launcher or Docker mapping, or explicit `--host`, `--port`, `WEB_UI_HOST`, and `WEB_UI_PORT` configuration. |
| 37 | 5. In Docker, framework checks belong to `/opt/venv-a0` and agent/user code execution belongs to `/opt/venv`. Do not use one runtime as proof for the other. |
| 38 | 6. Treat `/a0/` as the runtime framework root inside Docker. In local development it means the repository root. If a live container matters, prove that `/a0` matches the checkout before trusting source-only conclusions. |
| 39 | 7. Do not document or change ignored `usr/` or `tmp/` runtime state unless the user explicitly asks. |
| 40 | |
| 41 | ## Reference Map |
| 42 | |
| 43 | Load references with: |
| 44 | |
| 45 | ```json |
| 46 | {"tool_name": "skills_tool:read_file", "tool_args": {"skill_name": "a0-development", "file_path": "references/<file>.md"}} |
| 47 | ``` |
| 48 | |
| 49 | | Need | Read | |
| 50 | |---|---| |
| 51 | | Runtime split, root layout, discovery order, path and port boundaries | `references/architecture-runtime.md` | |
| 52 | | DOX edit workflow, when to update docs, file-level DOX checks | `references/dox-workflow.md` | |
| 53 | | Tool contracts, locations, prompts, and verification | `references/tools.md` | |
| 54 | | Python/WebUI extension discovery, hook points, ordering, implicit hooks | `references/extensions.md` | |
| 55 | | HTTP API, WebSocket handlers, WebUI extension surfaces | `references/api-webui.md` | |
| 56 | | Agent profiles, prompts, skills, projects | `references/agents-prompts-skills-projects.md` | |
| 57 | | Plugin-first workflow, where to put new work, handoffs to plugin skills | `references/plugins-workflow.md` | |
| 58 | |
| 59 | ## Working Flow |
| 60 | |
| 61 | 1. Classify the request: tool, extension, API/WebUI, profile, prompt, skill, project, plugin, runtime, or docs. |
| 62 | 2. Read the root `AGENTS.md`, then the nearest child `AGENTS.md` files for the target paths. |
| 63 | 3. Read the focused reference file from this skill. |
| 64 | 4. Inspect the current source files named by the reference before making a claim or patch. |
| 65 | 5. Keep changes narrow and in the repo-owned surface. Prefer `usr/` for user-created runtime content, but do not document ignored user state unless requested. |
| 66 | 6. Update DOX when a durable contract, path, behavior, workflow, responsibility, or verification rule changes. |
| 67 | 7. Run targeted checks from the relevant DOX file. For skill-only changes, at minimum verify frontmatter parsing, reference paths, and markdown sanity. |
| 68 | |
| 69 | ## Handoffs |
| 70 | |
| 71 | - Plugin creation: load `a0-create-plugin`. |
| 72 | - Plugin management or installation: load `a0-manage-plugin`. |
| 73 | - Plugin debugging: load `a0-debug-plugin`. |
| 74 | - Plugin review or publishing: load `a0-review-plugin` or `a0-contribute-plugin`. |
| 75 | - Agent profile creation: load `a0-create-agent`. |
| 76 | - Skill creation or skill format work: load `build-skill`. |
| 77 | |
| 78 | ## Closeout |
| 79 | |
| 80 | Report the exact files changed, the grounding checks used, whether DOX was updated or intentionally left unchanged, and what verification ran. If a claim depends on a live Docker runtime, include the runtime proof, not only checkout evidence. |