wiki (v2)

CRITICAL, Before starting, you MUST use the Read tool to read ../lark-shared/SKILL.md, which contains authentication and permission handling.

Member Management Hard Constraints:

• If the target is a "department", determine the identity first before deciding whether to proceed.
• --as bot corresponds to tenant_access_token. Official limitation: Under this identity, you cannot add wiki space members using a department ID (opendepartmentid).
• When encountering "department + --as bot", do not call lark-cli wiki +member-add for trial and error; state directly that this path is not feasible.
• If the user explicitly requests "run as bot" and the target is a department, you must stop and explain that the bot path cannot complete the request. Do not silently switch to --as user.

Identity Selection: Prioritize user identity

Wiki spaces and nodes are personal user resources. Strategically, you should prioritize explicit use of --as user (the CLI --as default value is auto, and when --as is omitted, it is often parsed as bot, listing the space belonging to the application rather than the user). Only use --as bot when the user explicitly requests "application / bot perspective" (still subject to the member management hard constraints above).

Quick Decision Making

• When a user wants to organize / inventory / classify / refactor a knowledge base, personal document library, document library directory, or Wiki node structure, or wants to generate an organization plan, target directory tree, or migration plan, do not use only Wiki node APIs. You must first read ../lark-drive/references/lark-drive-workflow-knowledge-organize.md. This workflow is responsible for unified entry parsing, resource inventory, classification planning, pre-write confirmation, and result verification for Drive / Wiki / personal document libraries.
• If the user provides a knowledge base URL (.../wiki/<token>) and subsequently wants to check/add/remove members: first call lark-cli wiki spaces get_node --params '{"token":"<wiki_token>"}' to obtain the space_id. Use the space_id for all subsequent member interface calls.
• When a user wants to delete a knowledge space (wiki +delete-space) but only provides the name or URL: Do not pass the name/URL directly to --space-id. You must first resolve the actual space_id. Resolution method:
  • URL (.../wiki/<token>): lark-cli wiki spaces get_node --params '{"token":"<wiki_token>"}' --format json, read data.node.space_id.
  • Name only: lark-cli wiki spaces list --format json, collect items while paginating and perform exact matching on name; stop paginating as soon as at least one exact match is accumulated on any page. Only when all pages have been exhausted (has_more=false) and there is still no exact match, perform fuzzy matching on the full set of collected items (trim name spaces, case-insensitive, substring inclusion).
  • Critical Security Constraint: Regardless of whether it is an exact or fuzzy match, and regardless of whether 1 or multiple items are hit, you must list the candidates (name + space_id + description + space_type) to the user before initiating deletion. The user must explicitly select a space_id before execution. Do not automatically execute deletion just because "only one item was hit".
  • 0 hits: Stop and ask the user if the name is misspelled or if the caller lacks permissions; do not attempt to modify the name and retry on your own.
  • After the user explicitly selects, execute lark-cli wiki +delete-space --space-id <ID> --yes (high-risk write operation, must have explicit --yes).
  • Counter-example: Do not use a wiki URL / name directly as --space-id (e.g., --space-id "https://.../wiki/<wiki_token>"); always use wiki spaces get_node to resolve the data.node.space_id first.
• When a user wants to create a new node in a knowledge base, prioritize using lark-cli wiki +node-create.
• When a user says "add member/admin to knowledge base": first parse the target into one of the four categories: "user / group / department / application", then decide on --member-type. Do not call wiki +member-add first and then infer the type based on error messages.
• When a user says "department + bot": this is a known unsupported path. Do not continue to try wiki +member-add --as bot; prompt directly that it must be changed to --as user, or clearly state that the current request cannot be completed.
• When a user says "user / group / application + add member": first resolve the corresponding ID, then execute wiki +member-add.
• When a user says "view / list space members": use wiki +member-list; this shortcut defaults to only one page, so explicitly add --page-all for multi-member scenarios.
• When a user says "remove / delete space member": use wiki +member-remove, you must provide the original --member-type and --member-role used during granting (if unknown, check first with wiki +member-list).

Shortcuts (Recommended)

Shortcuts are high-level wrappers for common operations (lark-cli wiki +<verb> [flags]). Prioritize using operations that have shortcuts.

Member Addition Process

• Before calling lark-cli wiki +member-add, parse the "person / group / department / application" in natural language into the correct --member-id. Do not guess the format.
• For user scenarios, default to --member-type=openid: use lark-cli contact +search-user --query "<name/email/phone>" --format json to obtain open_id.
• For group scenarios, use --member-type=openchat: use lark-cli im +chat-search --query "<group name keyword>" --format json to obtain chat_id.
• For application scenarios, use --member-type=appid: pass the application ID for --member-id, usually in the format cli_xxx.
• userid / unionid should only be used when explicitly requested by downstream; first obtain the open_id, then call lark-cli api GET /open-apis/contact/v3/users/<open_id> --params '{"user_id_type":"open_id"}' --format json to read user_id / union_id.
• For department scenarios, use --member-type=opendepartmentid: the current CLI has no shortcut, you need to call lark-cli api POST /open-apis/contact/v3/departments/search --as user --params '{"department_id_type":"open_department_id"}' --data '{"query":"<department name>"}' to obtain open_department_id.
• Only call lark-cli wiki +member-add after the target type and identity have been confirmed as feasible. For department scenarios, this means it must be --as user.

Target Semantic Constraints

• 我的文档库 / My Document Library / 我的知识库 / 个人知识库 / my_library should all be treated as Wiki personal library, not the Drive root directory.
• When processing such targets, first resolve the actual space_id corresponding to my_library, then execute wiki +move, wiki +node-create, or other Wiki write operations.
• Do not degrade to drive +move just because an explicit space_id is missing.
• Only enter the Drive domain for processing if the user explicitly mentions Drive folders, cloud space (cloud drive/cloud storage) root directory, or 我的空间.

API Resources

lark-cli schema wiki.<resource>.<method>   # Must check --data / --params structure before calling native APIs, do not guess field formats
lark-cli wiki <resource> <method> [flags]  # Call API

spaces

• create, Create a knowledge space
• get, Get knowledge space information
• get_node, Get knowledge space node information
• list, Get knowledge space list

members

• create, Add knowledge space member
• delete, Remove knowledge space member
• list, Get knowledge space member list

nodes

• copy, Create a copy of a knowledge space node
• create, Create a knowledge space node
• list, Get list of knowledge space child nodes

Out of Scope for this Skill

• Uploading / downloading files to a knowledge base node → lark-drive (drive +upload --wiki-token)
• Editing document body content → lark-doc
• Spreadsheet / Base data operations → lark-sheets / lark-base
• Searching for documents / Wiki / spreadsheet files by name, comments, and permission management → lark-drive