mirror of
https://github.com/agent0ai/agent-zero.git
synced 2026-10-19 07:23:51 +00:00
Fix trailing commas in six JSON examples while preserving all examples and thoroughness instructions. Rewrite 23 skill descriptions to fit the catalog preview, retaining existing triggers and adding explicit discovery phrases where needed. Document the description preview contract and add regression checks for complete JSON examples, description lengths, and skill search. All four checks pass against the staged snapshot.
4.2 KiB
4.2 KiB
| name | description | version | author | tags | trigger_patterns | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| a0-development | Develop Agent Zero itself: framework, tools, API/WebUI, prompts, runtimes and DOX. | 1.1.0 | Agent Zero Team |
|
|
Agent Zero Development
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.
Reality Rules
- Source and nearest DOX beat memory, examples, and this skill if they disagree.
- Before editing, read the applicable
AGENTS.mdchain from the repo root to every file you expect to touch. - New capabilities should usually be plugins. For plugin-specific work, load
a0-plugin-routerand follow the routed specialist skill. - Do not assume ports. Discover WebUI host/port from startup output, launcher or Docker mapping, or explicit
--host,--port,WEB_UI_HOST, andWEB_UI_PORTconfiguration. - In Docker, framework checks belong to
/opt/venv-a0and agent/user code execution belongs to/opt/venv. Do not use one runtime as proof for the other. - Treat
/a0/as the runtime framework root inside Docker. In local development it means the repository root. If a live container matters, prove that/a0matches the checkout before trusting source-only conclusions. - Do not document or change ignored
usr/ortmp/runtime state unless the user explicitly asks.
Reference Map
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 |
Working Flow
- Classify the request: tool, extension, API/WebUI, profile, prompt, skill, project, plugin, runtime, or docs.
- Read the root
AGENTS.md, then the nearest childAGENTS.mdfiles for the target paths. - Read the focused reference file from this skill.
- Inspect the current source files named by the reference before making a claim or patch.
- 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. - Update DOX when a durable contract, path, behavior, workflow, responsibility, or verification rule changes.
- Run targeted checks from the relevant DOX file. For skill-only changes, at minimum verify frontmatter parsing, reference paths, and markdown sanity.
Handoffs
- Plugin creation: load
a0-create-plugin. - Plugin management or installation: load
a0-manage-plugin. - Plugin debugging: load
a0-debug-plugin. - Plugin review or publishing: load
a0-review-pluginora0-contribute-plugin. - Agent profile creation: load
a0-create-agent. - Skill creation or skill format work: load
build-skill.
Closeout
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.