Dingtalk Docs 0.3.1

管理钉钉云文档中的文档、文件夹和内容。当用户想要创建文档、搜索文档、读取或写入文档内容、创建文件夹整理文档时使用。也适用于用户提到云文档、在线文档、钉钉文档、钉文档等关键词的场景。不要在用户需要操作多维表、管理日程、发消息或处理审批流时触发。

Security Scan

The skill's functionality (managing DingTalk cloud docs) is coherent, but there are clear mismatches between its declared metadata and what the package and runtime scripts actually require—most notably an unstated dependency on the mcporter CLI and a credential URL—so you should review configuration and origin before installing.

Purpose & Capability

The skill's name/description and SKILL.md consistently describe DingTalk cloud doc operations and the included scripts implement those operations. However, package.json declares a required binary (mcporter) and a credential (DINGTALK_MCP_DOCS_URL), while the top-level registry metadata lists no required binaries or env vars. This mismatch is incoherent: the scripts clearly need mcporter to function and a configured service URL, so the registry metadata underreports requirements.

Instruction Scope

SKILL.md instructions stay inside the stated purpose (create/search/read/write docs, create folders, etc.) and explicitly constrain risky actions (confirm updateType, require full docUrl, etc.). The runtime scripts follow these rules and include safety checks (path sandboxing, extension/size limits). The only scope issue is that instructions and scripts rely on an external CLI (mcporter) and mcporter-configured credential URL; SKILL.md/README mention this, but the top-level manifests do not.

Install Mechanism

There is no install spec in the skill bundle (instruction-only), yet code files are included that call an external binary (mcporter). package.json lists mcporter as a peer dependency and recommends installing it globally, but installation of mcporter is not automated. This is a transparency/usability concern: the skill will fail or behave unexpectedly if mcporter is not present or configured. There is no download-from-untrusted-URL behavior in the bundle itself.

Credentials

The code does not directly read arbitrary secrets or unrelated environment variables. It uses OPENCLAW_WORKSPACE to constrain file access (with reasonable defaults) and relies on mcporter (which uses a configured Streamable HTTP URL containing an access token). package.json documents a credential named DINGTALK_MCP_DOCS_URL (stored via mcporter config or env), but the registry metadata for the skill did not declare that required credential—an inconsistency that could mislead users into not providing/locking a sensitive token. The number/type of env variables requested is proportionate to the task, but verify where the access token is stored and who can read it.

Persistence & Privilege

The skill does not request elevated platform privileges, does not set always:true, and does not modify other skills' configs. It runs as-needed via mcporter calls. Autonomous invocation is allowed (default) but not combined with other high-risk indicators here.

What to consider before installing

What to check before installing/using this skill: - Metadata mismatch: package.json and README clearly expect the mcporter CLI and a configured DingTalk MCP URL (access token), but the registry metadata lists no required binaries or env vars. Treat this as a red flag: the skill will not work correctly unless mcporter is installed and configured. - mcporter dependency: the Python scripts call 'mcporter' via subprocess. Ensure you trust and have installed mcporter (npm or other official source) before running these scripts. If mcporter is missing, the skill's scripts will fail. - Credential handling: the service URL (DINGTALK_MCP_DOCS_URL) includes an access token. The skill relies on mcporter config (or an env var per package.json). Make sure that token is stored securely and not exposed to untrusted parties. Verify where mcporter stores its config and who/what can read it on your system. - Repository provenance: package.json points to a GitHub repo but the skill 'Source' and 'Homepage' are marked unknown/none in the registry metadata. Verify the upstream repository (does https://github.com/aliramw/dingtalk-docs exist and look legitimate?) before trusting the package. - File access constraints: import/export scripts enforce allowed extensions, size limits, and resolve paths against OPENCLAW_WORKSPACE. To limit accidental data exposure, set OPENCLAW_WORKSPACE to a dedicated directory and run the skill from there. - If you need to be cautious: do not install/execute the provided scripts until you confirm mcporter is legitimate and the DingTalk MCP URL you configure belongs to your account. If the author or repository cannot be validated, prefer to avoid granting the token or running the scripts. Additional info that would make this benign: the registry metadata explicitly listing mcporter as a required binary and the DINGTALK_MCP_DOCS_URL credential, plus a verifiable homepage/repo controlled by the vendor. If those are corrected and the upstream repo looks trustworthy, the inconsistencies would be resolved.

钉钉云文档 Skill

Overview

用户可能要求你创建、搜索、读取或编辑钉钉云文档。操作之间存在严格依赖关系：必须先获取 ID 才能执行后续操作。

严格禁止

1. 禁止编造 ID -- dentryUuid 必须从返回值中提取，编造 ID 会操作到错误文档或报错
2. 创建前必须先获取根目录 ID -- 必须先调 get_my_docs_root_dentry_uuid 拿到 rootDentryUuid
3. 禁止混淆两个创建方法 -- create_doc_under_node 只能创建文档，create_dentry_under_node 支持文件夹/表格/PPT 等多种类型
4. 写入前必须确认 updateType -- 0=覆盖（清空后写入），1=续写（追加到末尾），搞反会丢数据，不确定时必须先问用户
5. 禁止只传 ID 读内容 -- 必须拼成完整 URL https://alidocs.dingtalk.com/i/nodes/{dentryUuid}
6. 禁止在用户说"表格"时默认创建文档 -- 可能要在线表格(accessType="1")或多维表(accessType="7")，不确定必须先问
7. 禁止传错参数类型 -- accessType 必须是字符串，updateType 必须是数字，类型传错会导致静默失败

可用方法列表

方法	用途	必填参数
get_my_docs_root_dentry_uuid	获取"我的文档"根目录 ID	无
list_accessible_documents	搜索有权限的文档	无 (keyword 选填)
create_doc_under_node	创建在线文档	name, parentDentryUuid
create_dentry_under_node	创建节点 (文档/表格/文件夹等)	name, accessType, parentDentryUuid
write_content_to_document	写入文档内容 (覆盖或续写)	content, updateType, targetDentryUuid
get_document_content_by_url	通过 URL 获取文档 Markdown 内容	docUrl

意图判断

用户说"创建文档/新建文档/写个文档/帮我建个文档":

• 创建文档 → 先 get_my_docs_root_dentry_uuid，再 create_doc_under_node
• 创建到指定文件夹 → 用文件夹的 dentryUuid 作为 parentDentryUuid

用户说"建文件夹/新建目录/整理一下文档":

• 创建文件夹 → create_dentry_under_node(accessType="13")

用户说"创建表格/建个PPT/做个脑图":

• 非文档类型 → create_dentry_under_node，accessType: 表格="1"，PPT="2"，脑图="6"，多维表="7"
• 用户说"表格"但不确定类型 → 先问是在线表格还是多维表

关键区分: 在线表格(accessType="1") vs 多维表(accessType="7") vs 文档(用 create_doc_under_node)

用户说"搜索/找文档/查一下/有没有某个文档":

• 搜索 → list_accessible_documents(keyword=关键词)

用户说"读文档/看看内容/打开文档/这个文档写了什么":

• 有 URL → 直接 get_document_content_by_url
• 有文档名 → 先 list_accessible_documents 搜索，拿到 dentryUuid，拼 URL 再读

用户说"写入/更新内容/编辑文档/往文档里加点东西":

• 全新内容或替换 → write_content_to_document(updateType=0) 覆盖
• 追加内容 → write_content_to_document(updateType=1) 续写
• 不确定 → 问用户是覆盖还是追加

核心工作流

创建文档并写入:

1. get_my_docs_root_dentry_uuid() → 提取 rootDentryUuid
2. create_doc_under_node(name, parentDentryUuid=rootDentryUuid) → 提取 dentryUuid
3. (HARD-GATE: 必须确认 updateType) write_content_to_document(content, updateType=0, targetDentryUuid=dentryUuid) → 提取写入结果
4. get_document_content_by_url(docUrl="https://alidocs.dingtalk.com/i/nodes/{dentryUuid}") → 验证

搜索并读取:

1. list_accessible_documents(keyword="关键词") → 提取 docs[].dentryUuid
2. get_document_content_by_url(docUrl="https://alidocs.dingtalk.com/i/nodes/{dentryUuid}")

创建文件夹并整理:

1. get_my_docs_root_dentry_uuid() → 提取 rootDentryUuid
2. create_dentry_under_node(name, accessType="13", parentDentryUuid=rootDentryUuid) → 提取 dentryUuid
3. create_doc_under_node(name, parentDentryUuid=文件夹dentryUuid)

上下文传递规则

操作	从返回中提取	用于
get_my_docs_root_dentry_uuid	rootDentryUuid	create_doc_under_node / create_dentry_under_node 的 parentDentryUuid
create_doc_under_node	dentryUuid	write_content_to_document 的 targetDentryUuid，拼 URL 读内容
create_dentry_under_node	dentryUuid	作为子节点的 parentDentryUuid
list_accessible_documents	docs[].dentryUuid	拼成 https://alidocs.dingtalk.com/i/nodes/{dentryUuid} 用于读取

CRITICAL: 参数格式

// [正确] docUrl 必须是完整 URL
{"docUrl": "https://alidocs.dingtalk.com/i/nodes/DnRL6jAJ..."}
// [错误] 只传 ID → 报错
{"docUrl": "DnRL6jAJ..."}

// [正确] accessType 是字符串
{"name": "报表", "accessType": "1", "parentDentryUuid": "xxx"}
// [错误] accessType 传数字 → 静默失败
{"name": "报表", "accessType": 1, "parentDentryUuid": "xxx"}

// [正确] updateType 是数字
{"content": "...", "updateType": 0, "targetDentryUuid": "xxx"}
// [错误] updateType 传字符串 → 静默失败
{"content": "...", "updateType": "0", "targetDentryUuid": "xxx"}

错误处理

1. 遇到错误: 展示错误信息给用户，不要自行猜测解决方案
2. "Invalid credentials": 提示用户重新配置凭证
3. "Permission denied": 提示用户确认对该文档有操作权限
4. "Document not found": 用 list_accessible_documents 重新搜索确认文档是否存在
5. 错误码 52600007: 可能是企业账号限制或父节点 ID 无效，确认 parentDentryUuid 来源

详细参考 (按需读取)

• references/api-reference.md -- 完整参数 Schema + 返回值 + 节点类型枚举
• references/error-codes.md -- 错误码说明 + 调试流程