wecomcli-doc-manage

wecom-cli is a tool provided by the plugin, not a terminal command: all operations are completed by calling this tool, and parameters should be passed using args . It is forbidden to use it through command-line methods such as exec / shell / terminal.

⚠️ Prerequisite: Before calling wecom-cli for the first time, you must perform the prerequisite check according to the wecomcli-preflight skill to ensure the tool has been added to the whitelist.

Core Concepts

• Four Document Types: Online Document doc, Online Spreadsheet sheet, Smart Sheet smartsheet, Smart Document smartpage。doc_type . The enum is reused across multiple APIs.
• Additional Types Supported by the Search API: Collection Form collect、PPT ppt, Mind Map mind, Flowchart flow, Report journal、PDF pdf. These types are only available in the doc_types filter of the "Search Documents" API; other APIs (rename, permissions, join rules, etc.) do not apply.

Scope of Application

Applicable：

• Only supports searching doc documents / online spreadsheets / smart sheets / smart documents / PPT / collection forms / mind maps / flowcharts / reports / PDF document types
• Only supports modifying the names of doc documents / online spreadsheets / smart sheets / smart documents
• Only supports adding member permissions for doc documents / online spreadsheets / smart sheets / smart documents
• Only supports setting join rules for doc documents / online spreadsheets / smart sheets / smart documents

API Routing Table

If the second column of the routing table is references/xxx.md link → you must first use the read tool to finish reading that file, then construct the command.

User Intent	Reference Location
Search documents (including recently viewed/created)	See "Search Documents" below
Modify document name	+names-update
Add document members / change permissions	+members-update
Set link join rules	+rules-update

API Details

Search Documents

Search documents by keyword and filter conditions (type / creator / viewer-member / time window / sorting)

Regarding "viewer" and "member": under the search semantics of this API, the two are equivalent—visitor_userids matches documents where "that userid is a viewer/member/related party"; it can be used to express "including X", "X participated in", "related to X", or "X as a member".Note the permission constraint: no matter whose userid is passed, the final result will only returnthe current caller themselves has permission to access. Documents that others have permission to access but you do not will not appear in the results, so this API cannot be used to "spy on other people's exclusively held document lists".

How to Call

Use the wecom-cli tool to call in the following format

wecom-cli doc search --json '<JSON 参数>'

Parameters

Field	Type	Required	Default Value	Semantics
keywords	string[]	Yes	—	Keyword array, OR relationship. Pass an empty array when filtering only by other conditions []
search_scope	string	No	title_content	Search scope enum:title(title only) / title_content(title and content, default) / content(content only)
doc_types	string[]	No	—	Restrict type, value is a doc / sheet / smartsheet / smartpage / collect / ppt / mind / flow / journal / pdf subset of
creator_userids	string[]	No	—	Restrict to list of creator userids (typical: pass current user userid to query "recently created by me")
visitor_userids	string[]	No	—	Restrict to list of "viewer / member" userids
created_after / created_before	string	No	—	Creation time window,YYYY-MM-DD HH:mm:ss
opened_after / opened_before	string	No	—	Recently opened time window,YYYY-MM-DD HH:mm:ss
sort_by	string	No	best_match	Sort enum:best_match(default) / create_time(creation time) / modify_time(modification time)
limit	int	No	10	Return limit, no more than 100
cursor	string	No	—	Pagination cursor; pass empty on first call, subsequently take from previous page's next_cursor

Return

Field	Type	Description
has_more	boolean	Whether there is a next page;true when true, use next_cursor to continue fetching
next_cursor	string	Next page cursor
docs	array	Result document list, fields of each item are shown in the table below

docs[] Fields of a single document:

Field	Type	Description
docid	string	Unique document ID
doc_name	string	Document name
doc_type	string	Document type
url	string	Accessible document link
creator_userid	string	Document creator userid
create_time / modify_time	string	Creation / last modification time
title_highlight / text_highlight	string[]	Highlighted matched fragment

Usage rules

• ppt / journal / collect / mind / flow Currently no downstream skill or CLI can read the body text, when these types are matched and the user wants to view the content, directly inform them that reading is not currently supported, and guide the user to use doc_url to open and view within the WeCom client.
• Parameter combinations dispatched by intent (including required constraints): First determine the user's intent, then assemble parameters according to the corresponding branch. It is forbidden to pass no parameters at all or only empty values (such as {}）。
  • (a) Find by content → keywords(required, must not be an empty array) + search_scope=title_content + sort_by=best_match
  • (b) "Recently browsed by me / related to me / I am a member / documents containing me" → visitor_userids=[<当前 userid>](required, must not be empty) + sort_by=best_match + opened_after(default last 7 days)
  • (c) "Contains someone as a member / someone participated" (others) → visitor_userids=[<他人 userid>](required, first via wecomcli-contact resolved from name) + sort_by=best_match；Must remind the user: Only the portion of documents that the current caller has permission to access will be returned; documents that are exclusively the other party's and that you have no permission to access will not appear.
  • (d) "Recently created by me" → creator_userids=[<当前 userid>](required, must not be empty) + created_* time window + sort_by=create_time + created_after(default last 7 days)
  • If the intent does not belong to (b)(c)(d), handle it as (a) in all cases,keywords is required.
• userid(prefix wo）: when the user provides a name, resolve it via 读取 wecomcli-contact 技能 to userid; do not treat names as userid concatenation; do not fabricate from memory or guesswork.
• keywords must first tokenize then assemble: when the user gives a natural language query (such as "帮我找下产品的待办tool文档"), do not pass the entire query directly as a single keyword. Processing flow:
  1. Tokenize the query in Chinese and English to obtain a token list (Chinese split by word, English split by spaces / case boundaries), and remove colloquial / generic / stop words such as "help me", "find", "document", "of".
  2. Determine the "required tokens": from the remaining tokens, pick out the core words that truly carry the user's search intent (usually proper nouns, product names, feature names, and other strongly distinguishing words); the rest serve as auxiliary tokens.
  3. Assemble the keywords array: the 1st element is the string of all "required tokens" joined by spaces (only join the required ones; do not stuff all tokens in), and the subsequent elements are each individual token in order (required + auxiliary). For example, for the query "帮我找下产品的待办tool文档", after tokenization the required tokens are ["待办", "tool"], then keywords = ["待办 tool", "待办", "tool"]。
  4. If there is only 1 required token, the 1st element is that token itself; there is no need to append it again. For example, for the query "周报" → keywords = ["周报"]。
• Multiple candidates must be confirmed by the user: when there is >1 result, display the candidate list according to the "Result Display Specification" below, and wait for the user to choose before continuing with subsequent actions.
• When there are no candidates, you must ask the user: when the result = 0, tell the user that no document has been found at present, and ask whether the user can provide more keyword clues.

Example: user query "帮我找下产品的待办tool文档"

Remove generic words such as "help me / find / of / document", leaving ["产品", "待办", "tool"]; determine the core search intent as "待办" and "tool", so the required tokens are ["待办", "tool"]，"产品" as auxiliary tokens.

Use the wecom-cli tool to call in the following format

wecom-cli doc search --json '{"keywords":["待办 tool","待办","tool","产品"],"search_scope":"title_content","limit":10}'

Result Display Specification

When displaying search results to the user (including single items and multiple candidates), strictly comply with:

• Display them one by one as a markdown unordered list; tables are prohibited——display at most 10 results; even if there are only 2~3 results, use a list; a table forces four-column alignment and instead exposes noisy fields such as ID / time together.
• The document name must be a clickable link: write the first line of each item as - [doc_name](url)，url take the url field returned by the interface and use it as is.
• By default, do not display the creator：creator_userid is an internal ID and must not be output to the user in any form.

Cross-skill dependencies

Dependent skill	Typical collaboration scenario	Data flow
wecomcli-contact	When adding a document member, the user provides only a name, which must first be resolved to userid	wecomcli-contact 's contact users search → returns userid → this skill's doc members update interface

Need to read and open the searched docid

Obtaining docid is only the first step. Reading/opening the document body is another type of skill,mustaccording to doc_types, first read the SKILL.md of the corresponding "content skill", then issue commands according to its documentation:

• doc(online document) → wecomcli-doc skill
• smartpage(smart document) → wecomcli-smartpage skill
• sheet(online spreadsheet) → wecomcli-sheet skill
• smartsheet(Smart Table) → wecomcli-smartsheet Skill It is strictly forbidden to directly piece together a "read the main text" command; before reading the main text for the first time, you must read the SKILL.md of the corresponding content skill above, and all commands must be based on that SKILL.md.

Multiple search candidates require confirmation / search intent type confirmation / required parameters (docid, permission role, etc.) are missing, use concise natural language to ask only about the missing or ambiguous information; when there are candidate options, list them in the text for the user to choose, and do not guess on your own.