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.

Decide create versus edit

• Bound edit session: Runtime injection supplies the target. Omit both <operation> and <agent_id> and patch only that Agent.
• Unbound session: always emit <operation> first with exactly create or edit. The host does not infer intent from <agent_id>.
• Unbound create: emit <operation>create</operation> and omit <agent_id>.
• Unbound edit: emit <operation>edit</operation> plus the canonical <agent_id> of an existing custom Agent. Read the current spec first as required by source-and-editing.md.
• A host correction never changes the operation. Correct the rejected fields while preserving create or edit; if an edit target cannot be resolved, ask the user and emit no create container.
• Pure discussion, unrelated questions, or a request that changes no field: emit no container.

For a new Agent, first compare its name and its typical objects/actions with the injected Agent index. If an existing Agent substantially overlaps, stop and ask whether to use it or still create a new one. Otherwise create in the same turn.

Routing descriptions

New or rewritten descriptions usually need one or two concise sentences: action, work object, deliverable, and any boundary needed to distinguish adjacent roles. Use natural routing terms; add an example only to resolve ambiguity, not a repeated keyword list. Keep execution steps out of the description. Do not shorten supplied or existing descriptions during unrelated edits or source-preserving imports.

Execution sequence

1. Classify the runtime as LLM-managed or CLI-backed and the session as bound or unbound.
2. Read only the reference files required by the routing table above.
3. Read any required current Agent spec or user-supplied source.
4. Validate the intended fields, category, capability dependencies, interaction shape, and safety boundary.
5. Emit concise user-facing prose plus the smallest valid patch container. On create, include every required creation field. On edit, omit unchanged fields; list-like fields replace the entire list when present.
6. Stop after emitting the container; the host supplies persistence evidence.

Safety gate

Do not author direct access to credentials/private stores, dynamic or decoded execution, download-and-execute pipelines, startup persistence, runtime self-modification of Agent/Skill specs, or writes outside the authorized workspace. Convert required values into explicit user inputs or stop and explain the boundary.