market/skills/create-agent/SKILL.md

license, name, description, version, compatibility, type, risk_level, status, disable-model-invocation, tags, metadata, market

license	name	description	version	compatibility	type	risk_level	status	disable-model-invocation	tags	metadata	market
MIT	create-agent	通过多轮对话收集需求，调用 ManageAgent 内置工具创建新的 AgentFS v2 智能体，支持自定义 persona 和 principles。Use when 用户要求创建新智能体、培养某领域助手、或快速基于模板生成可治理 Agent。可选头像生成需配置图像服务，适用供应商条款/额度及独立费用。	2.7.0	DesireCore ManageAgent; optional avatar generation requires a configured image provider under its own terms and quota, with separate charges; unavailable generation retains the existing avatar.	meta	low	enabled	true	agent creation meta	author updated_at i18n desirecore 2026-10-03 default_locale source_locale locales zh-CN en-US en-US zh-CN zh-CN en-US name short_desc description body source_hash translated_by 创建智能体 通过自然语言对话收集需求，一键创建专业化数字智能体 通过多轮对话收集需求，调用 ManageAgent 内置工具创建新的 AgentFS v2 智能体，支持自定义 persona 和 principles。Use when 用户要求创建新智能体、培养某领域助手、或快速基于模板生成可治理 Agent。可选头像生成需配置图像服务，适用供应商条款/额度及独立费用。 ./SKILL.zh-CN.md sha256:7ffb7a362c26a91e human name short_desc description body source_hash translated_by Create Agent Collect requirements through natural-language conversation and create a specialized digital Agent in one step Collect requirements through multi-turn conversation and call the ManageAgent builtin tool to create a new AgentFS v2 Agent, with customizable persona and principles. Use when the user asks to create a new Agent, raise a domain assistant, or quickly produce a governable Agent from a template. Optional avatar generation requires a configured image service under provider terms/quota and separate charges. ./SKILL.md sha256:7ffb7a362c26a91e human	icon category maintainer compatible_agents channel required_client_version <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none"><defs><linearGradient id="ca-a" x1="2" y1="7" x2="16" y2="21" gradientUnits="userSpaceOnUse"><stop stop-color="#34C759"/><stop offset="1" stop-color="#007AFF"/></linearGradient></defs><circle cx="9" cy="7" r="4" fill="url(#ca-a)" fill-opacity="0.15" stroke="url(#ca-a)" stroke-width="1.5"/><path d="M16 21v-2a4 4 0 0 0-4-4H6a4 4 0 0 0-4 4v2" fill="url(#ca-a)" fill-opacity="0.1" stroke="url(#ca-a)" stroke-width="1.5"/><circle cx="19" cy="11" r="4" fill="#34C759" fill-opacity="0.15"/><line x1="19" y1="8.5" x2="19" y2="13.5" stroke="#34C759" stroke-width="2" stroke-linecap="round"/><line x1="16.5" y1="11" x2="21.5" y2="11" stroke="#34C759" stroke-width="2" stroke-linecap="round"/></svg> productivity name verified DesireCore Official true latest 10.0.108

create-agent skill

L0: One-Sentence Summary

Collect requirements through natural-language conversation and call the ManageAgent builtin tool to create a specialized digital Agent.

L1: Overview

Meta-skill: gather requirements over multi-turn conversation → generate persona/principles → land via ManageAgent(action='create'). Use it to raise a domain specialist (legal advisor, financial analyst), deploy a customized business Agent quickly, or produce a prototype from a template. The created repo conforms to the AgentFS v2 spec and is version-managed by git (governable, traceable). Its value is what the tool can't give: domain-tailored persona/principles generation + a pre-create preview confirmation.

L2: Detailed Spec

Flow: intent recognition → requirement gathering → content generation → user confirmation → creation → receipt.

Stage 1: Intent Recognition

Trigger (any): user explicitly says "create an Agent / make me an assistant"; describes a domain-specific need the current Agent lacks; asks "can you raise a …". Confirm intent, then move to requirement gathering.

Stage 2: Requirement Gathering

• Required (parenthesized = example prompt question): name ("what to name it?"), role ("what does it mainly do?"), target_users ("who will use it?"), domain ("what expertise does it need?").
• Optional: style (communication tone), boundaries (red lines), language (default Chinese) — defaults derived from the domain template.
• Strategy: prefer inferring from the user's natural description; only ask for missing required fields; you decide how many to ask and the pacing.

Stage 3: Content Generation

Organize persona and principles as structured fields (do not emit raw markdown; present field-by-field). Leave uncollected fields empty for the system to fill with defaults:

• persona: L0 one-sentence core identity; L1 role / personality (array of trait tags) / communication_style; L2 specialty, values, decision preferences (free-form).
• principles: L0 one-sentence top principle; L1 must_do / must_not (safety red lines) / priority; L2 governance principles, escalation rules (free-form).

Domain matching reference (recommend personality and red lines by domain):

Domain	Recommended personality	Default must_not
Legal / contract	Professional, rigorous, prudent	No litigation representation; not a substitute for formal legal advice
Finance / accounting / investment	Precise, analytical, conservative	No investment advice; no real transactions
Code / development / architecture	Logical, pragmatic, direct	No direct production access; no credential storage
General / other	Friendly, helpful	Standard safety norms

Stage 4: User Confirmation

Present the preview in natural language / tables (name, description, persona, principles; no raw markdown source), e.g.:

About to create "Legal Advisor Assistant" — focused on contract review and legal risk assessment. Persona: digital legal advisor; professional, rigorous, prudent; uses legal terms accurately with plain-language explanations. Principles: user interest first, not a substitute for formal legal advice; must — cite statutes / mark uncertainty / recommend consulting a lawyer; must not — litigation representation / leaking consultations; priority: user safety > accuracy > efficiency. Confirm creation? (Confirm / Modify / Cancel)

If the user picks "Modify": ask which field → re-collect that field → update the preview → show and confirm again.

Stage 5: Create via ManageAgent

Structured call (persona/principles also accept markdown strings; unprovided fields are auto-filled):

ManageAgent({
  "action": "create",
  "name": "Legal Advisor Assistant",
  "description": "A digital Agent focused on contract review and legal risk assessment",
  "persona": { "L0": "…", "L1": { "role": "…", "personality": ["professional","rigorous","prudent"], "communication_style": "…" } },
  "principles": { "L0": "…", "L1": { "must_do": ["…"], "must_not": ["…"], "priority": "user safety > accuracy > efficiency" } }
})

• Minimal create needs only { "action": "create", "name": "My Assistant" } (everything else auto-generated).
• Basic create { "action": "create", "name": "Legal Advisor", "description": "contract review" } — with just name + description, the description auto-fills persona's L0.
• Optional id (kebab-case slug; core / desirecore are reserved core identifiers and cannot be used, including when the slug auto-generated from name collides), config, smartRouting, and avatarImage. See the contracts below. Sensitive fields such as mcp_servers and tool_permissions are rejected and must be adjusted through the UI after creation.
• The Agent is registered and usable immediately; the returned ID works directly with ManageTeam / Delegate. If the tool errors (already exists / reserved identifier / non-whitelisted config field, etc.), explain the reason and retry after adjusting per the hint.

Creation Parameter Guide

Smart routing: new Agents default to the Smart flagship tier. When responsibilities require an explicit tier, pass smartRouting:

{
  "tier": "balanced",
  "requiredCapabilities": ["vision", "tool_use"],
  "reasoning": "high"
}

• tier accepts lightweight, balanced, or flagship; reasoning accepts auto, off, minimal, low, medium, high, xhigh, or max.
• Omitting tier defaults to flagship. This expresses workload and capability intent, not a concrete Provider or model.
• Fixed model, Provider, and Smart/fixed selection are governed by the human model selector and cannot be changed through ManageAgent.
• Natural-language requests such as "deepest/highest/max it out" normally map to xhigh; use max only when the user explicitly names it and the model supports it.

Configuration patch: config supports only llm and declarative avatar settings. It is normally unnecessary during creation; use it only when the Agent needs a different default reasoning behavior:

{
  "llm": {
    "reasoning": "high",
    "maxRetryDelayMs": 30000
  },
  "avatar": {
    "char": "L",
    "color": "purple"
  }
}

config.llm currently exposes only reasoning, thinkingBudgets, and maxRetryDelayMs. Do not pass model, provider, providerId, or routingMode.

Image avatar: use the separate avatarImage parameter; do not place image data in config:

{ "source": "dc-media://<mediaId>" }

source may be a media ID from the current turn or a PNG/JPEG/WebP file inside the working directory. URLs and base64 are rejected. The service crops to 512×512 WebP and removes EXIF automatically. Avatar failure does not roll back an otherwise successful Agent creation; retry only the avatar operation according to the receipt.

Automatic asynchronous avatar

Check readiness through the current governed tool catalog: use ManageCompute(action="list") for enabled/credential status and InspectModels(action="list", serviceType="image_gen") for an eligible image model. Neither listing proves upstream quota or call success; follow provider terms/quota and separate charges. Do not read keys or use local HTTP. If these tools are absent, follow the configuring-compute skill's governed GUI observation. If generation is known unavailable, create with avatarGeneration.enabled:false, preserve the character avatar and report the limitation; this opt-out also covers unavailable service, not only user refusal. Unknown readiness is not success; inspect the background task result and do not fabricate completion.

Generation requires a configured image provider and its own service terms/quota; provider charges are separate from this skill. Without a usable provider, keep the character avatar and report the failed task.

Read the actual ManageAgent schema. On clients exposing avatarGeneration, creation automatically queues a transparent photorealistic portrait without waiting for generation. Do not ask for appearance preferences when the user has none, and do not call GenerateImage a second time for the same creation. Preserve explicit user requirements with avatarGeneration.prompt; use transparentBackground:false only for an explicitly requested background, or enabled:false when the user explicitly wants no generated image. Supplying avatarImage.source takes precedence. Inspect queued/running/completed/failed/interrupted state through ManageAgent(get); failure retains the character avatar and does not require recreating the Agent. On an older client without the field, follow its declared schema and never send unsupported parameters.

Stage 6: Receipt

Present in a user-friendly way (no internal paths / technical details): confirm success and suggest next steps — start chatting, add skills, adjust persona or rules.

Background and Constraints

• AgentFS structure, troubleshooting, and protected paths: see _agentfs-background.md and _protected-paths.yaml.
• Always create via ManageAgent; never use curl / HTTP or write AgentFS directories directly. Requires client ≥ 10.0.90.