wecomcli-doc-manage

Before executing any
wecom-cli
command, you must read and complete the public pre-checks of the
wecomcli-shared
skill.

Core Concepts

Four Document Types: Online document
```
doc
```
, online spreadsheet
```
sheet
```
, smart spreadsheet
```
smartsheet
```
, smart document
```
smartpage
```
. The
```
doc_type
```
enumeration is reused across multiple interfaces.
Additional Types Supported by Search Interface: Collection form
```
collect
```
, PPT
```
ppt
```
, mind map
```
mind
```
, flow chart
```
flow
```
, report
```
journal
```
, PDF
```
pdf
```
. These types are only available in the
```
doc_types
```
filter of the "Search Documents" interface and are not applicable to other interfaces (rename, permission, joining rules, etc.).

Scope of Application

Applicable:

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

Interface Routing Table

If the second column of the routing table is a

references/xxx.md

link → you must first read the file using the

read

tool before constructing the command.

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

Interface Details

Search Documents

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

Regarding "viewers" and "members": In the search semantics of this interface, they are equivalent —
visitor_userids
hits documents where "the userid is a viewer/member/stakeholder". It can be used to express "includes X", "participated by X", "related to X", "X as a member", etc. Note on Permission Constraints: No matter whose userid is passed, the final results will only return documents that the current caller has permission to access; documents that others have permission to access but you don't will not appear in the results, so this interface cannot be used to "snoop on others' exclusive document lists".

Command

bash

wecom-cli doc search --json '<JSON parameters>'

Parameters

Field	Type	Required	Default Value	Semantics
`keywords`	string[]	Yes	—	Array of keywords, in OR relationship. Pass an empty array `[]` when filtering only by other conditions
`search_scope`	string	No	`title_content`	Search scope enumeration: `title` (title only) / `title_content` (title and content, default) / `content` (content only)
`doc_types`	string[]	No	—	Restrict types, subset of `doc` / `sheet` / `smartsheet` / `smartpage` / `collect` / `ppt` / `mind` / `flow` / `journal` / `pdf`
`creator_userids`	string[]	No	—	Restrict list of creator userids (typical: pass current user's userid to check "my recently created")
`visitor_userids`	string[]	No	—	Restrict 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	—	Recent opening time window, `YYYY-MM-DD HH:mm:ss`
`sort_by`	string	No	`best_match`	Sorting enumeration: `best_match` (default) / `create_time` (creation time) / `modify_time` (modification time)
`limit`	int	No	`10`	Return upper limit, no more than 100
`cursor`	string	No	—	Pagination cursor; pass empty for the first time, take `next_cursor` from the previous page for subsequent requests

Return

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

Fields of a single document in

docs[]

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 / recent modification time
`title_highlight` / `text_highlight`	string[]	Hit highlighted fragments

Usage Rules

Currently, no downstream skill or CLI can read the content of
ppt
/
journal
/
collect
/
mind
/
flow
. When these types are hit and the user wants to view the content, directly inform them that reading is not supported yet, and guide them to open the document in the WeCom client using
```
doc_url
```
.
Parameter combinations are assigned by intent (including mandatory constraints): First determine the user's intent, then assemble parameters according to the corresponding branch. It is forbidden to pass no parameters or only empty values (such as
```
{}
```
).
- (a) Search by content →
```
keywords
```
  (required, cannot be empty array) +
```
search_scope=title_content
```
  +
```
sort_by=best_match
```
- (b) "My recently viewed / related to me / I am a member / documents that include me" →
```
visitor_userids=[<current userid>]
```
  (required, cannot be empty) +
```
sort_by=best_match
```
  +
```
opened_after
```
  (default: last 7 days)
- (c) "Include someone as a member / someone participated" (others) →
```
visitor_userids=[<other userid>]
```
  (required, first resolve from name via
```
wecomcli-contact
```
  ) +
```
sort_by=best_match
```
  ; must remind the user: only documents that the current caller has permission to access will be returned, documents that the other party has exclusive access to and you don't will not appear.
- (d) "My recently created" →
```
creator_userids=[<current userid>]
```
  (required, cannot 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 according to (a),
```
keywords
```
  is required.
userid
(prefix
wo
): When the user provides a name, resolve it to
```
userid
```
by
```
reading the wecomcli-contact skill
```
; it is forbidden to use the name as
```
userid
```
for splicing, and forbidden to make up based on memory or guesses.
keywords
must be segmented before assembly: When the user gives a natural language query (such as "Help me find the product's to-do tool document"), it is forbidden to directly pass the entire query as a single keyword. Processing flow:
1. Perform Chinese-English word segmentation on the query to get a token list (Chinese segmented by words, English segmented by spaces / case boundaries), and remove colloquial / general / stop words such as "help me", "find", "document", "de".
2. Determine "mandatory tokens": Select core words that truly carry the user's retrieval intent from the remaining tokens (usually proper nouns, product names, function names, etc. with strong distinguishability), and the rest as auxiliary tokens.
3. Assemble the
```
keywords
```
  array: The first element is a string formed by concatenating all "mandatory tokens" with spaces (only mandatory ones, do not include all tokens), followed by individual tokens (mandatory + auxiliary). For example, query "Help me find the product's to-do tool document", after segmentation, mandatory tokens are ["待办", "tool"], then
```
keywords = ["待办 tool", "待办", "tool"]
```
  .
4. If there is only 1 mandatory token, the first element is the token itself, no need to append it repeatedly. For example, query "Weekly report" →
```
keywords = ["周报"]
```
  .
Multiple candidates must be confirmed by the user: When there are >1 results, display the candidate list according to the "Result Display Specification" below, and wait for the user to select before proceeding with subsequent actions.
No candidates must prompt the user: When there are 0 results, inform the user that no documents were found, and ask if they can provide more keyword clues.

Example: User query "Help me find the product's to-do tool document"

Remove general words like "help me / find / de / document", remaining ["产品", "待办", "tool"]; determine the core retrieval intent as "待办" and "tool", so mandatory tokens are ["待办", "tool"], "产品" as auxiliary token.

bash

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

Result Display Specification

Strictly follow these rules when displaying search results to users (including single and multiple candidates):

Display item by item using markdown unordered list, do NOT use tables——Display up to 10 results, use a list even if there are only 2~3 results; tables force four-column alignment, which exposes noise fields like ID / time instead.
Document name must be a clickable link: Write the first line of each item as
```
- [doc_name](url)
```
, use the
```
url
```
field returned by the interface as-is for
```
url
```
.
Do not display creator by default:
```
creator_userid
```
is an internal ID, it is forbidden to output it to the user in any form.

Cross-skill Dependencies

Dependent Skill	Typical Collaboration Scenario	Data Flow
`wecomcli-contact`	When adding document members, the user only provides a name, which needs to be resolved to `userid` first	`contact users search` of `wecomcli-contact` → returns `userid` → `doc members update` interface of this skill

Need to read and open the searched docid

Getting the

docid

is only the first step. Reading/opening the document content is another type of skill. You must first read the SKILL.md of the corresponding "content skill" according to doc_types, then send 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 spreadsheet) →
```
wecomcli-smartsheet
```
skill It is strictly forbidden to directly assemble commands for "reading content"; before reading content for the first time, you must read the SKILL.md of the above corresponding content skills, and commands must be based on that SKILL.md.

When multiple search candidates need confirmation / search intent needs confirmation / mandatory parameters (such as
docid
, permission role, etc.) are missing, use concise natural language to only ask for the missing or ambiguous information; when there are candidates, list them in the text for the user to choose, do not guess on your own.