dingtalk-misc

Long-tail product collection Skill (dingtalk-misc)

Routing before execution

This file is only responsible for product routing. First determine the unique product from the table below: a single, clear Whiteboard, Attendance, Report, Sheet, or Dev task directly reads the corresponding reference (which contains the minimum execution contract required for that task); other products first read dingtalk-shared, then read the unique product reference. Only read one precise shared reference when authentication, profile, confirmation, or error recovery is actually triggered; do not pre-read on cold start.

When the same request simultaneously contains daily report, weekly report, or briefing names together with approval intent such as approver, cc recipient, approval path, or approval form, the approval intent takes precedence, and it is uniformly routed to OA and reads oa.md; this task must not execute dws report. If OA has no template with the same name, it also must not downgrade to submit a Report; it may only deliver OA search results or request disambiguation. Only when the user explicitly requests submission of a DingTalk log and there is no approval-flow semantics should it route to Report.

Attendance tasks directly read the single best-matching attendance*.mdaccording to the product index; do not repeatedly pre-read dingtalk-shared. Only when cross-product orchestration, profile/authentication issues, unknown global errors occur, or a Reference explicitly points to shared should the corresponding shared content be read on demand.

When the user explicitly requests creating or operating a whiteboard file or standalone whiteboard, directly read whiteboard.md, without first reading Doc or shared routing. Class schedules, calendars, flowcharts, etc. are content forms and cannot be used as a basis to change an in-document embedded target into a standalone whiteboard. Card container operations for in-document embedded whiteboards go through dingtalk-doc; only graphical content operations for an existing host document nodeId and partId read the whiteboard reference. If either identity is missing, stop and fill it in; converting to a standalone whiteboard is prohibited.

Product index table

Trigger keywords	One-sentence scope	Command prefix	Detailed reference
OA / approval / pending approval / agree / reject / cancel / initiated approvals / initiate approval / approval attachment / create template / update template	OA approval query and processing; creation, attachments, and template writing load special instructions on demand	dws oa	First read core oa.md; for initiating approval then read oa-create.md; for attachment operations then read oa-attachments.md; for creating/updating templates then read oa-template-write.md
Legal / smart contracts / contract ledger / contract archiving / contract projects / counterparties / contract payments	Smart contract ledger, import, drafting, archiving, projects, counterparties, and payment management	dws contract	contract.md
Attendance / clock-in / shifts / attendance groups / scheduling / attendance reports / leave balance	Attendance records, rules and configuration, scheduling, reports, leave	dws attendance	Daily query/rules/settings:attendance.md; shift import or shift table export:attendance-schedule.md; attendance Excel/report export:attendance-report.md; leave/balance:attendance-vacation.md
Live stream / my live streams / live stream list	Live stream list and live stream record query	dws live	live.md
DING / urgent notification / phone DING / SMS DING / must-reach message	DING urgent message (in-app/SMS/phone), personal DING	dws ding	ding.md
Open platform app / enterprise internal app / app status or deletion conditions / app management members / app permissions / app version or version history / agentId / clientId / app bot configuration / bot message mode or online status / local bot connector / Stream connection / version release / connect / MCP service development / MCP tool release / MCP credentials / OpenAPI or Swagger or Postman or curl to MCP / interface for Agent use / published MCP invocation	Open platform enterprise internal apps, as well as MCP services, tools, authentication, credentials, collaborators, and dynamic invocation after release	dws dev / dws dev mcp / dws mcp published	Read one according to the "Dev direct access rules" below references/dev/*.md; only read when the intent is unclear dev-index.md
DEAP digital employee / digital employee / persona / group awareness / DSH integration	Compatibility routing; full natural language orchestration is maintained only by an independent dingtalk-tag skill	dws dingtalk-tag	Switch dingtalk-tag
Goal management / strategy decoding / business contract fields / scorecard / OKR / goal rule cycles / personal goals / goal templates / weekly and monthly report rule statistics / on-time late unsubmitted / follow-up reminders	Agoal goal management and business goal tracking	dws agoal	agoal.md
Daily report / weekly report / monthly report / write log / inbox log / outbox log	Log (daily/weekly/monthly report) query and submission by template	dws report(alias dws log）	report.md
Spreadsheet / worksheet / cell read and write / formula / hyperlink / floating image	Spreadsheet creation/read-write/formula/hyperlink/floating image/export	dws sheet	sheet.md
Open platform documentation / API documentation / interface documentation / interface error	Open platform development documentation search	dws devdoc	devdoc.md
Unwrapped OpenAPI / llms.txt / dws api / Raw API / API escape hatch	Official llms.txt hierarchical discovery, generates and confirms Raw calls only for enterprise internal app App Token server-side APIs	dws api	openapi-explorer.md
Whiteboard file / standalone whiteboard / save to whiteboard / canvas / OpenNodes / whiteboard node / SVG pre-rendering	Content-bearing creation, local SVG pre-rendering, reading, pre-write diff preview, and updating of standalone whiteboards	dws whiteboard	whiteboard.md
Existing in-document embedded whiteboard graphic content with hosting document nodeId and partId	Only read and write the graphic content within that part; card container insertion, positioning, and deletion go through dingtalk-doc; stop when identity is missing, do not change to a standalone whiteboard	dws whiteboard --node ... --part-id ...	whiteboard.md
Search skills / find skills / install skills / skill marketplace / install DWS mono or multi skill	DWS skill marketplace search, download, installation, and built-in skill deployment	dws skill	skill.md
Talent pool / reserve cadre pool / employee profile / career history / performance records / employee tags / organizational brain / talent search	Organizational brain: talent pool, employee profile specialized modules, and structured talent search	dws hrbrain	hrbrain.md
Native Markdown / .md original text / Markdown version comparison / local draft diff / overwrite Markdown / partial replace Markdown / Markdown comments	Native .md file reading, creation, version or draft comparison, full overwrite, partial replacement, and comment list	dws markdown	markdown.md
Native HTML / .html file / create new HTML page / upload HTML file / read HTML original text / overwrite HTML / partial replace HTML	Native .html/.htm File reading, creation, full overwrite, and partial replacement (DingTalk Drive or document space)	dws html	html.md
PAT authorization / behavior permission / scope authorization / one-time authorization / session authorization / permanent authorization / authorization browser policy	PAT behavior authorization and local browser policy	dws pat	pat.md
Switch organization / change organization / cross-organization / multi-organization / profile / see which organizations are logged in	Multi-organization / profile management and cross-organization data retrieval	dws profile / dws auth / --profile	profile.md
Yida / AI application scripts / financial auxiliary scripts (not productized)	NoneStable command surface; only auxiliary scripts within the repository	(not the default route)	unsupported-scripts.md

Description

• When a digital employee is matched, immediately switch to the independent dingtalk-tag; this skill does not retain duplicate reference documents.
• After a product is matched, its references/<product>.mdmust be read; do not infer commands from the index alone. Report is read-only report.md; the common Sheet closed loop is read-only sheet.md; for complex tasks, load sub-references in the order of the stages entered, at most one per stage and at most three for regular tasks; batch pre-reading or repeated reading is prohibited.
• Agoal / Report boundary: filling in, submitting, or querying the body of ordinary daily/weekly/monthly reports goes through Report; rule-level submission statistics, counts of on-time/late/not-submitted people, personnel lists, and follow-ups go through Agoal. The appearance of "monthly report" cannot by itself assign it to Report; it must be judged together with business words such as "rule/statistics/late/not submitted/follow-up".
• Attendance exception: according to the index table, directly read the single best-matching attendance*.md; do not first read attendance.md and then read the scheduling, report, or leave-specific Reference. Only when a single task truly spans two independent attendance domains should a second one be loaded.
• Attendance performance optimization is only allowed to reduce repeated loading of shared/Reference/Help/Schema and repeated remote queries; it is prohibited to omit records, business fields, pagination, failed items, warnings, or post-write verification required by the user in order to save tokens. When a "all/complete" conclusion is required, integrity evidence such as endpoint exhaustion/total count must be retained and checked.
• Attendance command paths, flags, constraints, and return declarations are authoritative based on the current live Cobra/Contract/precise leaf Schema; the attendance Reference only maintains business routing, capability boundaries, and workflows. Execute known commands directly; when there is genuine uncertainty, read the precise compact leaf at most once, avoiding information drift caused by copying the full command set.
• A product's own local intent disambiguation document is named references/<product>-intent-guide.md, not the shared references/intent-guide.md。
• If cross-product collaboration among products points to another product within this package, it has already been written in the corresponding references/<product>.md as "see references/X.md in this package", and there is no need to switch skills; if it points to a top10 independent product (such as chat/aisearch/doc), still switch skills according to dingtalk-<product> .
• scripts/ Under yida / finance / aiapp_create_and_poll.py etc., see unsupported-scripts.md; by default, do not call them as formal capabilities.
• Dev direct rules: application status, create/delete/update/query, whether it can be deleted→app.md; credentials→credentials.md; management member/role summary of an open platform application→member.md, not Chat group members; permissions→permission.md; security configuration→security.md; web application→webapp.md; robot online configuration→robot.md; version history/pending release version/release→version.md; event subscription→event.md; local bot connector/Stream connection →connect.md; MCP → read firstmcp.md, and only when entering the corresponding phase incrementally read its API conversion, mapping, authentication, expression, or fault-location sub-reference; do not pre-read the entire set at once; when it is clear that more than two Dev domains are involved → only read firstrecipes.md. For a single-domain task, read only one; for cross-domain, also do not pre-read each topic, and only read one additional reference when a real response shows a special status or field not covered by this page. No need to read first dingtalk-shared、devapp.md or the index, and do not repeatedly read the Reference.
• Dev command discipline: by default use the auditable dws dev ... atomic path, and do not call dws dev help, subgroup help, or dws devapp +...to discover shortcuts. To locate an app by name there is only dws dev app list --name, there is no dws dev app search; for existing apps, use dws dev app robot getfor bot names, modes, and statuses, and do not use dws chat bot; connectors are dws dev connect ..., not under dws dev app . Execute known leaves directly; only when the current parameters are genuinely uncertain, read that leaf's compact Schema once, and only when the Schema is unavailable call the exact leaf once --help. Do not use group help to scout.
• Dev JSON and pagination: all commands carry --format json；connect list/status and must also carry their own --json, otherwise the actual output is a table.app list、permission list、event list、version list only accepts cursor pagination: read the returned meta.pagination.endpoint_exhausted/next_token, and pass --cursor <next_token>for the next page; do not guess --page、--page-num, and do not look in data for the old-version hasMore/nextCursor。
• Dev completion discipline: before execution, note every deliverable requested by the user; execute in dependency order, and put cleanup such as deletion/deactivation last. The user's initial request for a write operation only authorizes dry-run, not formal confirmation after seeing the precheck. You must first show the dry-run's exact object, action, business parameters, and impact, then obtain the user's explicit confirmation of that preview; afterward, only replace the same command's --dry-run with --yes, and if the target or any business parameter changes, dry-run again, show, and confirm. Do not send a non-dry-run write call before confirmation;--dry-run is not completion. After writing, do only one necessary read-back. Do not retry the same business error when the parameters and state have not changed; retry once only after new evidence actually changes the command, parameters, or state. Answer item by item in the end; for an empty list also explicitly write "none for now", and do not use large blocks of raw JSON to crowd out other results.
• Devapp cross-domain fast path: to create/clean up an app plus capabilities such as bots, web pages, and members, first read dev/recipes.md , and do not pre-read the app or each topic. Only add the exact section if a parameter is missing; a failed creation cannot borrow another app. In a confirmed follow-up turn, directly execute the confirmed and unchanged command, and after completing the necessary read-back, continue in the same turn with the next item's dry-run and ask for confirmation of that item, without separately asking "whether to continue". Reuse IDs, receipts, and already-read references; if the target/parameters change, still re-precheck and reconfirm. For explicit STREAM, pass --mode STREAM; if you are not creating a connection, do not read connect; if it is explicitly not to be published, do not enter the publishing chain.
• DevDoc search budget: for an explicit development documentation task, directly read devdoc.md, no cold-start pre-reading of shared or Devapp is needed. For each topic, search the original phrase first; when there are no results or all are irrelevant, perform at most one well-grounded rewrite in ordinary lookup, then report the miss. When query terms and page counts are specified, do not substitute or reduce them without authorization; having returns does not equal finding relevant material, and consecutive synonym searches or cross-product searches to try one's luck are prohibited.
• OA tasks should first read the core oa.md. Only when entering the actual ticket-submission stage should you incrementally read oa-create.md, only when handling approval attachments should you incrementally read oa-attachments.md, and only when creating or updating templates should you incrementally read oa-template-write.md; do not pre-read the full set of creation, controls, nodes, attachments, and template writes for ordinary queries. If real-time notification is required when future approval tasks or instances change, switch to the independent dingtalk-event. Open platform application event configuration still belongs to DevApp; follow dev/event.md and do not confuse it with personal real-time events.
• For the boundaries between native .md and online rich text adoc, and general file storage, see markdown.md; for native .html/.htm file reading and writing, see html.md; for cross-organization / profile rules, see profile.md。
• PAT behavior authorization is not open platform application permission; for the latter, see dev/permission.md。

When an Agent uses OpenNodes to create a whiteboard with content, it must first execute whiteboard render, display the SVG and rendering prompt, then stop and wait for the user to explicitly confirm the current version before creating; after modification, re-render and confirm again. Do not skip the preview and create directly. The initial creation request and the post-creation read-back cannot replace preview confirmation. See the creation process at the whiteboard entry point for details; blank creation, directly applying templates, and updating existing whiteboards are not extended by this rule.

When an Agent updates existing whiteboard content (append, modify, delete, clear), it must first execute whiteboard +diff, display the differences and risks, then stop and wait for the user to explicitly confirm the current differences, then use the same sourceDigest to execute +update; when diff fails or there is a blocker, do not write. Do not switch to atomic update to bypass this. render, dry-run, and post-write read-back cannot replace diff. See the update process at the whiteboard entry point for details. Updates have only one user confirmation point: first complete the required render and the necessary +diff, then present the visual preview (if any), the differences, and the overwrite impact together and confirm once; do not ask for confirmation after render first and then add the diff and ask again only after approval. Once the same target, revision, source, and mode have been confirmed, submit directly; only re-confirm if these contents change or undisclosed material risks appear.