dingtalk-tag

Digital Employee Skill

Before executing any dws operation, first fully read dingtalk-shared. First use dingtalk-tag-index.md for routing; for the lifecycle read manage.md, for natural-language creation/restoration/DSH integration then read manage-and-connect.md; for capability resources read capability.md; for execution troubleshooting read run.md。

Routing

User intent	Command
Create draft / Create and publish / Query / Modify / Publish / Delete	dws dingtalk-tag manage ...
Take offline	The current version has no independent take-offline command; explicitly state the limitation, and must not use delete to impersonate taking offline
A2A or other login-only scenarios	dws dingtalk-tag manage login --agent-uuid ...
Only log in to the digital employee and save the local Profile	dws dingtalk-tag manage login --agent-uuid ...
Integrate an existing, already-published local digital employee with DSH	dws dingtalk-tag connect --agent-uuid ... --channel dsh
Integrate the digital employee with the current local Agent	dws dingtalk-tag connect --agent-uuid ... --channel auto --daemon --alwayson
Query, stop, or restart the digital employee's local connection	dws dingtalk-tag connect list/status/stop/restart
Take over on a new machine (first complete unbinding on the old machine)	Old machine connect unbind After success, new machine dws dingtalk-tag connect --agent-uuid ... --channel ...
Disconnect this machine's connection, but keep the employee and Profile	dws dingtalk-tag connect unbind --agent-uuid ...
Switch an existing connection to another local Agent or DSH	First connect unbind --agent-uuid ..., then connect --agent-uuid ... --channel ...
Create, update, delete, or query Skill / MCP resources	`dws dingtalk-tag capability skill
Query the status or full trace of an execution	dws dingtalk-tag run ...

Hard constraints for natural-language orchestration

• The MCP main program type field for create/update is digitalTagEmployeeProfile.type, list filtering uses the top-level type, only supports open_code、local_agent，a2a not yet supported. The CLI parameter is --type; on creation, --type open_code|local_agentmust be explicitly passed; a missing or empty value is intercepted locally by DWS; the caller should be told to choose a main program type, and it cannot be omitted or sent as an empty value. On update, if not passed it remains the original value; when explicitly integrating with a local Agent/DSH, pass --type local_agent. Note that create/list/save-draft 's --type is the main program type, while detail uses --snapshot draft|published to select the configuration source; do not confuse them.
• If --response-mode is not provided on creation or the value is empty, the CLI sends mention_onlyby default, including local_agent. On update, if not passed the field is not updated, and an explicit value remains unchanged; the final effective configuration is validated by the server against the current draft.
• Creation requires a name, description, and main program type; the department may be omitted, and the server fills in the operator's primary department. Do not ask the user for a department name, position, employee ID, or internal uid.
• save-draft only updates the basic draft fields the user explicitly modified, and does not accept a complete Skill/MCP array. Skill/MCP lifecycle uniformly uses capability skill|mcp create|update|delete|list|query; do not design attach/detach,check_mcp is only called internally within create and update with configuration.
• When creating or replacing an MCP configuration, configString.mcpServers.<名称>.type（streamable-http or sse) as well as the corresponding urlmust be communicated and explicitly filled in; the URL alone cannot be filled in, andconfigType=JSON cannot replace the transport type either. Only updating enabled does not resubmit the configuration.
• The configuration required for publishing is validated by the server; the default response mode at creation time is mention_only. When a historical draft lacks a response mode, first use save-draft to fill it in; do not implicitly rewrite the draft via the publish command.
• Continuous write operations within the same natural language request are only confirmed in a single summary; only after confirmation add --yes. First use --dry-run --format json to display the plan.
• If saving or publishing fails after successful creation, you must return the created agentUuid and the recovery command; retries must not execute create again.
• "Create and persist Profile" can sequentially execute create/publish and manage login; "Create and connect DSH" instead uses connect --channel dsh. Create/publish and connect are independent transactions; connect never creates, modifies, or publishes a digital employee.
• Users can create/manage digital employees only, convert an existing employee only into a local Profile, or proceed to connect DSH; the three operations are not strongly bound to each other.
• Digital employee IDs uniformly use agentUuid / --agent-uuid; personnel identifiers uniformly use userId, and must not require or display uid, robotUid, staffId.
• Ordinary local Agent access uses Event Consume, and by default only the supervisor can trigger it; users in the whitelist must first be precisely resolved under the employee identity. Supports Codex, Qoder/QoderWork, Claude Code, CodeBuddy/WorkBuddy, Gemini, OpenCode, and custom. OpenClaw/Hermes is not yet adapted; do not fall back to the robot creation flow.
• The natural language "create, publish, and connect locally" explicitly uses --daemon --alwaysonafter publishing; the command line defaults to foreground. DSH does not add these two parameters; it is started at the employee level by the running host; when the host is unavailable, prompt to start the host according to restartRequired. connect does not provide auto-start on boot, and cannot process messages while the computer is asleep.
• After connect fails, retain the employee ID and the persisted Profile, check connect status and then recover; do not repeat create, do not clear the event retry budget, and do not implicitly overwrite another Adapter's binding.
• The server-side identity is injected by the supervisor login state, and passing userId/orgId is prohibited; deviceId is a stable device identifier, runtimeBindingId is a server-side binding ID, and is different from the local bindingRevision/runtimeInstanceId. A binding receipt does not mean online; a bind with an unknown response must not be automatically retried or bypassed by deleting configuration. To save only the Profile use manage login。
• "Pause" uses stop (retains the binding); "unbind" uses unbind (retains the Profile); "switch to another local Agent" first unbinds, and after success connects; both steps first dry-run and confirm in a summary. Before rebinding, first confirm the old instance is released; if unknown or timed out, do not manually delete the binding to bypass. If the new binding has been submitted but startup fails, use restart; if the old binding is still unbinding, retry the original unbind.

Security

• manage login internally completes AuthCode exchange, online identity verification, and saves the precise corpId:userId Profile; AuthCode/Token must not be output or stored elsewhere. To only log in or only save the Profile use manage login; to actually connect a local Agent/DSH use connect。
• Deletion is irreversible; modifications, publishing, deletion, and connect are executed according to the Schema's confirmation requirements.
• The Channel's reply / operator-private is only for use by the bound local Adapter/DSH machine protocol, must specify the employee Profile, and the body can only go through restricted stdin; do not call it directly for ordinary user messages.