dingtalk-shared

DWS Shared Execution Contract

This file serves as an entry point only when DWS is referred to generically, for cross-product flows, URL pre-checks, or unclear intent. For clear single-product requests, use the corresponding dingtalk-* skill directly; product root skills that already embed the minimal execution contract do not need to read this file in full first.

Minimal DWS Execution Contract

• Use only dws; structured reads plus --format json, judge by the actual return.
• For known commands, call directly; if parameters/constraints/security are unclear, check the narrow leaf Schema. Only when the Schema is unavailable, read the known leaf Help once;unknown flag correct once using the same leaf Help.unknown command Do not check Help: prefer explicit suggestions in the error, then explicit compatible entry points in loaded Skills/references; if neither exists, report drift and stop, do not search the entire Catalog. Do not default to Help for low-frequency references, and do not use root/parent/product Help. After discovery, it must be executed or the blockage explained.
• Do not guess commands/flags/fields/IDs/accounts/business facts; IDs come from real returns. For zero matches/multiple candidates/unknown types on a target, disambiguate first; use contract defaults only for optional time/display scope, and stop when required information is missing.
• Parse/read/write use the same profile, and IDs do not cross organizations. For multiple accounts, use only the unique isOrgCurrent=true; otherwise the user specifies, and it is forbidden to choose the first item, the most recent login, or the most recently used account.
• Do not output/record tokens, refresh tokens, appSecret, or webhook tokens; do not ask for them when authentication is already injected.
• Writes must match explicit intent; confirmation is subject to the final Runtime gate/Schema, and only after confirmation add --yes。
• Verify results after writing, and do not claim success based on exit codes. Exit must be in the final reply, distinguishing completed, partial, blocked, pending confirmation, and failed; preserve existing data and complete/hasMore/stopReason/failures。
• Display timestamps in the session time zone, and keep the original value when necessary.
• For authentication/permission/profile/confirmation/unknown errors, read only dingtalk-shared the corresponding reference, and do not repeatedly guess alternative commands.

International version, overseas version, or .io regional login must execute dws auth login --intl(for headless environments additionally add --device）；--intl is used only for login; subsequent business commands are automatically routed according to the selected profile.

Product or cross-product rules are loaded incrementally on top of the minimal contract. When the user has made the product content intent clear, intent takes precedence over URL form; for multi-account selection and cross-organization rules read ../dingtalk-misc/references/profile.md. Local files, product boundaries, and cross-product passing rules are loaded only in the corresponding tasks, avoiding putting the global manual into every single-product request.

Progressive Loading

Read only the files needed for the current task, and do not load all shared references at once:

Current Situation	Required Reading
A single product is already clear	Corresponding ../dingtalk-*/SKILL.md; do not read the routing reference
DWS is referred to generically and a product must be selected	routing.md
Cross-product, multi-step, aggregation, or reporting	workflow-routing.md
Input contains an alidocs /i/nodes/ URL provided directly by the user or a nodeId from an unverified source (even if the product intent is clear)	url-patterns.md; first normalize dlink, then enter the target product
The input contains other DingTalk URLs such as alidocs and shanji, and the type is unclear	url-patterns.md
Product boundaries are still difficult to determine	intent-guide.md the relevant sections of
Authentication, global flag, or output format issues	global-reference.md
The command has already returned an error	error-codes.md; only check the section corresponding to the error
confirmation_required / write operation confirmation	confirmation.md
Command discovery, Schema / --compact / --all	schema-usage.md
Suspect the capability is not supported	capability-limits.md
Batch/multi-source collection	conventions.md
Fixed short process	lite-catalog.md corresponding section

Product commands, scripts, and field details are in the corresponding product skill, not in dingtalk-shared duplicated maintenance.

Routing order when this skill is used as the entry point

1. First identify the clear product content intent; a clear intent directly selects the corresponding product. The alidocs /i/nodes/ URL or nodeId with an unverified source directly provided by the user must still be read url-patterns.md: first perform node type probe,extension=dlink when drive info of result.fileId save as the entry ID and pass to dws doc info, then follow linkSourceInfo.nodeId to resolve the target hop by hop, and hand the final target ID to the candidate product. The stable ID that the current call chain has returned with the real type can be reused directly.
2. The request contains multiple sequential steps, cross-product data transfer, or a summary report: even if the URL has been identified, also read workflow-routing.md, and combine the required product skills according to the action guide; the current release package does not include a standalone scenario skill.
3. The request is a single-product operation but the product is unclear: read routing.md, then explicitly read the target product SKILL.md。
4. doc/drive/wiki、aitable/sheet、calendar/minutes and other boundaries are still unclear: only read intent-guide.md the corresponding sections.
5. If it still cannot be determined, ask the user follow-up questions; do not guess the product or command.

Cross-skill execution

• Relative Read links in the body are runtime dependencies;metadata.requires.skills will not be loaded automatically.
• After selecting the target product, the target skill's commands, parameters, and risk rules take precedence.
• Multi-step processes pass real return values in order; read-only collection that can be parallelized is executed according to the corresponding workflow/reference, and write operations are serial by default and verified step by step.
• Clear operations already inlined in the product skill are executed directly; only read deeper references when encountering parameters or boundaries not covered by that skill.

Shortest error path

1. unknown command / unknown flag: run the corresponding level --help, correct according to the public flag, and retry at most once; when command selection is uncertain, read schema-usage.md。
2. reason=confirmation_required: handle according to confirmation.md , do not give up as an ordinary validation error or silently add --yes。
3. Authentication or permission errors: read global-reference.md and error-codes.md the corresponding sections.
4. Other errors: prefer reading retryable、retry_after_seconds、 next_retry_at、hint and actionsin the JSON error. Only retry at the server-side pace when retryable=true is explicit; when retry semantics are missing, use --verbose to obtain diagnostics and stop, and do not continuously try alternative commands.
5. Capabilities explicitly not supported: explain the boundary, and do not bypass them through other interfaces.