agent-creator

agent-creator

Create or edit a custom Agent by emitting one inline <agent>...</agent> container in the final reply. The host parses and applies the container; do not call a mutation tool or write agent.json directly.

Read only the reference needed for this request

The root file is the execution gate. Before emitting a container, read the matching reference through this Skill's read ref:

• New LLM-managed Agent, or an edit to its name, icon, description, workflow, guidance, Skills, tools, inputs, interaction mode, or category → llm-agent-fields.md.
• Creation from supplied files/prompts/specs, conversation crystallization, or an unbound edit of an existing Agent → also read source-and-editing.md. Current-turn requirements for inputs, checks, workflow, outputs, or non-goals count as a supplied spec, so this reference is required.
• CLI-backed Agent edit or a request about its external runtime boundary → read cli-and-prose.md.

Do not read unrelated references. A simple bound edit normally needs only llm-agent-fields.md; a CLI-backed edit normally needs only cli-and-prose.md.

Non-negotiable protocol

• Mutation only via the inline container. Never use edit_file, write_file, or bash to change agent.json. Never dump the container into a workspace file.
• No container, no mutation, no success claim. Without a valid container, describe the result only as a proposal, clarification, or blocker; never say the Agent is ready, created, updated, installed, or available. A valid container only requests a mutation; only the host result proves it was applied. Until then, use pending wording such as “将创建” or “已提交，等待应用”.
• One container per Agent. Multiple containers are legal only when the user asked to create or edit multiple distinct Agents, and the number of valid containers must equal the number of Agents you claim to have created. End the turn after emitting them; do not dispatch the Agent.
• Validate every container independently before sending. Read its tags in order: every opening tag must have the exact matching closing tag, with no crossed, missing, or reused closer. For a multi-Agent reply, repeat this structural check for each container rather than copying an unchecked suffix.
• Read attachment sources. For an injected attachment, missing inline body text is not a missing source; call read_files with the exact supplied path in paths and ask for another upload only if that read fails.
• Use the user's current UI language for display copy and user-visible prose. Keep XML tags, tool/Skill names, paths, JSON keys, and closed-set values unchanged. Use localized description tags only when the user explicitly requests multilingual descriptions.
• Keep user-visible prose outcome-based. State what the Agent does, when to use it, and the substantive change; do not expose XML/field/schema/id mechanics or source provenance by default.
• Agent roles are not model runtimes. Do not imitate or claim an unavailable provider by naming an ordinary role Agent after a model. Real external CLI runtimes are handled by their smaller editable contract.
• Do not hard-code other Agent display names in authored content; describe downstream roles by capability.
• Agent workflows invoke Skills by their visible names, not Skill files or installation paths. List every invoked Skill in <skills>. Built-in tool names belong to <tools>, never <skills>.
• Keep runtime guidance bounded. Use at most 5 items per field.
• Run the category sanity check. Do not accept an invalid source category or silently fall back to general when one domain clearly dominates.