skills/a0-development/SKILL.md
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.
AGENTS.md chain from the repo root to every file you expect to touch.a0-plugin-router and follow the routed specialist skill.--host, --port, WEB_UI_HOST, and WEB_UI_PORT configuration./opt/venv-a0 and agent/user code execution belongs to /opt/venv. Do not use one runtime as proof for the other./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.usr/ or tmp/ runtime state unless the user explicitly asks.Load references with:
{"tool_name": "skills_tool:read_file", "tool_args": {"skill_name": "a0-development", "file_path": "references/<file>.md"}}
| Need | Read |
|---|---|
| Runtime split, root layout, discovery order, path and port boundaries | references/architecture-runtime.md |
| DOX edit workflow, when to update docs, file-level DOX checks | references/dox-workflow.md |
| Tool contracts, locations, prompts, and verification | references/tools.md |
| Python/WebUI extension discovery, hook points, ordering, implicit hooks | references/extensions.md |
| HTTP API, WebSocket handlers, WebUI extension surfaces | references/api-webui.md |
| Agent profiles, prompts, skills, projects | references/agents-prompts-skills-projects.md |
| Plugin-first workflow, where to put new work, handoffs to plugin skills | references/plugins-workflow.md |
AGENTS.md, then the nearest child AGENTS.md files for the target paths.usr/ for user-created runtime content, but do not document ignored user state unless requested.a0-create-plugin.a0-manage-plugin.a0-debug-plugin.a0-review-plugin or a0-contribute-plugin.a0-create-agent.build-skill.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.