Skip to content
skillsafebeta
← Report library
Purpose / Data analysis

Lark Im Skill Security Audit

What the author says it does (original text)

飞书即时通讯：收发消息和管理群聊。发送和回复消息、搜索聊天记录、管理群聊成员、上传下载图片和文件、管理表情回复、发送应用内/短信/电话加急、发送和处理交互卡片（Interactive Card）、监听卡片按钮回调（card.action.trigger）。当用户需要发消息、查看或搜索聊天记录、下载聊天中的文件、查看群成员、搜索群、创建群聊或话题群、管理标记数据、管理 Feed 置顶（添加/移除/查询置顶会话）、管理标签数据、处理卡片回调时使用。

Independent security check

Do not install or run it yet

Files checked
61
Risks found
5
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 2
High risk

Forwarded Markdown can trigger remote downloads and upload fetched content to Feishu

Source references: 4
What we found

The Skill instructs agents to preserve original document text and send it with --markdown. The sender resolves remote Markdown image URLs by downloading and uploading them first. The visible rules do not restrict destination hosts, private addresses, or redirects.

Why this matters

A malicious or altered document can embed an image URL that causes the lark-cli environment to contact a tracking host or internal HTTP resource, then upload successfully fetched image content into a Feishu message.

When forwarding a Lark document, the Skill preserves its original Markdown; the send path resolves remote image URLs by downloading and then uploading them to Lark. If the document contains an untrusted image link, sending can make the local environment contact that address and upload the response as an image. No hostname, private-address, or redirect restriction is visible. Users can require a trusted HTTPS allowlist or removal/preview of remote images. Sending itself still requires explicit approval.

SKILL.md:79In the instructions
When sending content fetched from a Lark doc as a message, fetch the doc with --doc-format im-markdown, then send it as a message using the --markdown format. The fetched content is already in markdown; in any content-forwarding scenario, keep the fetched original text and send it in the --markdown format. Note: if the doc contains a cite tag with type="user", keep it as-is and do not strip the tag.
Show 3 other places
references/lark-im-messages-send.md:49In the instructions
The shortcut does all of the following before sending:1. Forces `msg_type=post`2. Resolves remote Markdown images like `![x](https://...)` by downloading and uploading them first3. Normalizes the Markdown for Feishu post rendering4. Wraps the result as:
references/lark-im-messages-send.md:75In the instructions
- Already-uploaded `img_xxx` image keys are the most reliable Markdown image input.- Local paths in Markdown image syntax like `![x](./a.png)` are **not** supported and will not be auto-uploaded.- Remote URLs (`https://...`) will be auto-downloaded and uploaded at runtime; if the download or upload fails, the image is removed with a warning.
references/lark-im-messages-send.md:11In the instructions
Messages sent by this tool are visible to other people. Before calling it, you **must** confirm with the user:1. The recipient (which person or which group)2. The message content3. The sending identity (user or bot)**Do not** send messages without explicit user approval.
Medium risk

Routine message reads expand to reactions and up to 500 thread replies by default

Source references: 3
What we found

Read commands attach reaction data by default, while mget and chat message listing automatically fetch replies for discovered threads, up to 500 replies per page. A request for main-stream messages or a small sample can therefore read substantially more conversation data and make extra API calls.

Why this matters

Agent context and command output may include unexpected thread content, participant reactions, and additional messages. The reactions scope also broadens the authorization surface.

The read shortcuts query reactions by default, while mget and chat-message listing also automatically fetch replies for every message carrying a thread_id, with a default cumulative limit of 500 replies per page. This can exceed an intent to inspect only a few top-level messages, exposing more conversation data and making extra API calls. `--no-reactions` only disables reaction lookup; no thread-expansion opt-out is visible. Users can bound pages and targets and request an explicit expansion switch.

SKILL.md:59In the instructions
The four message-pulling shortcuts (`+messages-mget`, `+chat-messages-list`, `+messages-search`, `+threads-messages-list`) automatically attach a `reactions` block and (for edited messages) `update_time` to each returned message — no separate `im.reactions.batch_query` call is needed. Pass `--no-reactions` to opt out. For the full contract (output shape, the `im:message.reactions:read` scope requirement, and the "missing field ≠ fetch failure" data rules), read [`references/lark-im-message-enrichment.md`](references/lark-im-message-enrichment.md).
Show 2 other places
references/lark-im-message-enrichment.md:13In the instructions
`+messages-mget` and `+chat-messages-list` also auto-expand thread replies: any returned message that carries a `thread_id` triggers a fetch of that thread's replies, which are attached as a `thread_replies` array on the host. Fetches across distinct threads run with bounded concurrency (up to 4 in flight). Two caps gate the result:- **`perThread` (default 50)** — max replies fetched for any single thread.- **`totalLimit` (default 500)** — max cumulative replies across all threads on the page.
references/lark-im-message-enrichment.md:9In the instructions
- **`update_time`** — emitted only when `updated == true` (message was actually edited). The server echoes `update_time == create_time` for unedited messages too, but the CLI gates that output away so consumers don't misread every message as "edited".- **Opt-out** — each shortcut accepts `--no-reactions` to skip the extra round-trip when the caller only needs message bodies.
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 2
High risk

Card auto-processing lacks operator authorization checks

Source references: 4
What we found

After a single confirmation, every callback is processed immediately. The workflow reads operator and form values, may classify a “business action” as requiring an update, and calls the update API, but the visible rules do not require validation of operator_id, chat_id, role, or allowed action.

Why this matters

Anyone able to interact with the card may drive changes to shared card state. If buttons are connected to approvals, tickets, or other business actions, an unauthorized participant could influence decisions or workflows.

The workflow obtains one confirmation before automatic handling, then directs each callback to be processed immediately and lets the model decide whether to update the complete card using the event token. The visible rules do not require per-event checks against operator_id, chat_id, role, or an action allowlist. An out-of-scope card user could therefore influence what all recipients see. Users can require operator/chat/action allowlists and a narrowly scoped listener.

references/lark-im-card-action-reply.md:95In the instructions
Only enter the auto-update workflow below if the user confirms. If your runtime does notsupport background monitoring, inform the user that automatic card updates are not availableand they will need to handle interactions manually.## Agent workflowWhen a `card.action.trigger` event arrives (**each stdout JSON line is one event — process it immediately**):
Show 3 other places
references/lark-im-card-action-reply.md:104In the instructions
```1. Read action fields to understand what the user did:   - action_tag: which component was triggered   - action_value / option / options / checked / input_value / form_value: what value was set2. Decide: does this interaction require a card update?   - e.g. button click with a business action → yes   - e.g. navigation / pagination → no (just record, no update needed)   - Not every callback requires a card update — decide based on business semantics   - Before updating, explicitly state what visual change the action requires. If you cannot articulate one, skip the update.3. If update is needed:   a. If card_content is empty: inform the user that the original card could not be fetched,      so it is not possible to determine whether an update is needed — do not guess   b. Determine the new card state based on the action   c. Use card_content as the structural basis to construct the updated card JSON   d. Detect card version: if card_content contains `"schema":"2.0"` or `"schema": "2.0"` it is Card 2.0; otherwise assume Card 1.0   e. For Card 1.0: include `"open_ids": ["<operator_id>"]` inside the `card` object, or the API returns code 300090   f. Call the delayed update API with the token and new card JSON
references/lark-im-card-action-reply.md:101In the instructions
When a `card.action.trigger` event arrives (**each stdout JSON line is one event — process it immediately**):```1. Read action fields to understand what the user did:   - action_tag: which component was triggered   - action_value / option / options / checked / input_value / form_value: what value was set2. Decide: does this interaction require a card update?   - e.g. button click with a business action → yes   - e.g. navigation / pagination → no (just record, no update needed)   - Not every callback requires a card update — decide based on business semantics   - Before updating, explicitly state what visual change the action requires. If you cannot articulate one, skip the update.
references/lark-im-card-action-reply.md:117In the instructions
      so it is not possible to determine whether an update is needed — do not guess   b. Determine the new card state based on the action   c. Use card_content as the structural basis to construct the updated card JSON   d. Detect card version: if card_content contains `"schema":"2.0"` or `"schema": "2.0"` it is Card 2.0; otherwise assume Card 1.0   e. For Card 1.0: include `"open_ids": ["<operator_id>"]` inside the `card` object, or the API returns code 300090   f. Call the delayed update API with the token and new card JSON
Medium risk

Troubleshooting may prompt an unnecessary contact-directory grant

Source references: 2
What we found

The main documentation states that sender names require no contact scope, but the mget permission-error advice tells users to enable contact:user.base:readonly as well. This can steer an ordinary message-read failure toward broader contact access.

Why this matters

A user may grant access to employee profile data merely to fix message reading, giving the application directory permissions unrelated to the requested task.

The main instructions say sender names come directly from the message API and require no contact-directory scope, while mget troubleshooting recommends enabling `contact:user.base:readonly` together with message-read access. This is guidance rather than automatic permission acquisition, but following it could grant contact-directory access unrelated to the stated name-resolution path. Users can authorize only message-read access first and ask the author to justify any separate contact feature.

SKILL.md:52In the instructions
- **Server-provided name**: the read APIs return `sender_name` (plus the full-i18n `sender_i18n_names` map) on each message `sender`; the CLI surfaces it as the sender's `name` for users and bots alike. No name lookup and no extra permission are needed — **no contact scope** and no `application:bot.basic_info:read`.- **Fallback to id**: when the server does not provide a name, the sender is shown by its id and the command still exits 0. There is no contact-directory fallback.
Show 1 other places
references/lark-im-messages-mget.md:94In the instructions
| `invalid message ID: must start with om_` | Invalid message ID format | Message IDs must start with `om_` || Permission denied | Message read permission is missing | Ensure the app has `im:message:readonly` and `contact:user.base:readonly` enabled || Empty result | Message IDs do not exist or are not accessible | Verify the IDs and access permissions |
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.Risks found: 1
Medium risk

Card failure retries lack an idempotency key and may send duplicates

Source references: 3
What we found

The card workflow uses a send command without --idempotency-key and instructs automatic retries up to three times, followed by a downgraded resend. If the server accepted a message but the client saw a timeout or lost response, the next attempt becomes a new message.

Why this matters

Recipients may receive duplicate notifications, approval cards, or action controls. Multiple live cards can also lead to duplicate approvals or business processing.

The card-send example omits an idempotency key, while failure handling directs up to three retries and then another downgraded send. If Lark accepted a request but the client reported failure because of a timeout or lost response, later calls could create duplicate cards. The send shortcut supports a one-hour idempotency key, so this gap is avoidable. Users can require every retry to reuse one key and verify uncertain outcomes before resending.

references/card/lark-im-card-create.md:101In the instructions
```bash# 发送到群聊lark-cli im +messages-send --chat-id oc_xxx --msg-type interactive --content '<card_json>'# 发送给指定用户（私聊）lark-cli im +messages-send --user-id ou_xxx --msg-type interactive --content '<card_json>'```
Show 2 other places
references/card/lark-im-card-create.md:109In the instructions
**发送失败时**：先对照下方常见失败列表排查，若能匹配则按对应处理方式修复后重新发送；否则根据错误信息修复 JSON 后重新发送。最多尝试 **3 次**。若 3 次后仍失败，**降级为 Card 1.0 卡片**重新构造并发送。**不参考之前发送 2.0 的记忆**，完全根据用户意图重新构造 1.0 卡片。1.0 无本地参考文档（components/、resource/ 均为 2.0）。**常见失败列表**
references/lark-im-messages-send.md:196In the instructions
| `--msg-type <type>` | No | Message type (default `text`). If you use `--text` / `--markdown` / media flags, the effective type is inferred automatically. Explicitly setting a conflicting `--msg-type` fails validation || `--idempotency-key <key>` | No | Idempotency key, max 50 characters; the same key sends only one message within 1 hour                                                                                                        || `--as <identity>` | No | Identity type: `bot` or `user` (default `bot`)                                                                                                                                                |

Inside this skill

6 instruction sections

This Skill uses lark-cli with either a user token or bot token to operate Feishu chats. It can read messages and members, send/edit/recall messages, and manage chats, shortcuts, and tags; effective access depends on the selected identity and granted scopes.

View source
SKILL.md:44In the instructions
- `--as user` means **user identity** and uses `user_access_token`. Calls run as the authorized end user, so permissions depend on both the app scopes and that user's own access to the target chat/message/resource.- `--as bot` means **bot identity** and uses `tenant_access_token`. Calls run as the app bot, so behavior depends on the bot's membership, app visibility, availability range, and bot-specific scopes.- If an IM API says it supports both `user` and `bot`, the token type changes who the operator is. The same API can succeed with one identity and fail with the other because owner/admin status, chat membership, tenant boundary, or app availability are checked against the current caller.
SKILL.md:153In the instructions
  - `create` — 将用户或机器人拉入群聊。Identity: supports `user` and `bot`; the caller must be in the target chat; for `bot` calls, added users must be within the app's availability; for internal chats the operator must belong to the same tenant; if only owners/admins can add members, the caller must be an owner/admin, or a chat-creator bot with `im:chat:operate_as_owner`.  - `delete` — 将用户或机器人移出群聊。Identity: supports `user` and `bot`; only group owner, admin, or creator bot can remove others; max 50 users or 5 bots per request.

The focused send, reply, and edit documentation requires confirmation of the target, content, and identity because these operations create externally visible changes.

View source
references/lark-im-messages-send.md:11In the instructions
Messages sent by this tool are visible to other people. Before calling it, you **must** confirm with the user:1. The recipient (which person or which group)2. The message content3. The sending identity (user or bot)**Do not** send messages without explicit user approval.
references/lark-im-messages-edit.md:11In the instructions
Editing rewrites a message visible to other people. Before calling it, you **must** confirm with the user:1. Which message to edit (its `message_id`)2. The new contentThe bot must be the original sender — editing another identity's message fails. Identity is always the bot: user identity is rejected server-side (`user access token not support`).**Do not** edit a message without explicit user approval.

Message reads query reactions by default and may automatically expand thread replies. Attachment downloading is separately opt-in and writes files under lark-im-resources in the current working directory.

View source
references/lark-im-message-enrichment.md:13In the instructions
`+messages-mget` and `+chat-messages-list` also auto-expand thread replies: any returned message that carries a `thread_id` triggers a fetch of that thread's replies, which are attached as a `thread_replies` array on the host. Fetches across distinct threads run with bounded concurrency (up to 4 in flight). Two caps gate the result:- **`perThread` (default 50)** — max replies fetched for any single thread.- **`totalLimit` (default 500)** — max cumulative replies across all threads on the page.
references/lark-im-message-enrichment.md:24In the instructions
`+chat-messages-list`, `+messages-mget`, and `+threads-messages-list` accept an **opt-in** `--download-resources` flag. It is **off by default** — when omitted, output and the request count are identical to before (no `resources` block, no extra round-trips).When enabled:- Each message that carries downloadable resources gets a `resources` array. Eligible types: `image`, `file`, `audio`, `video`, `media`, and post-embedded `img` / `media`. **Stickers are excluded** (Feishu does not support fetching sticker resources).- Each ref is `{message_id, key, type, local_path, size_bytes}` — `type` is `image` or `file`; `message_id` is the id used to fetch the resource. For a standalone message that is its own id; for a resource inside a **merge_forward** it is the **top-level container** `message_id`, not the sub-item's own id (the download endpoint rejects sub-item ids with `234003 File not in msg` and can only fetch a forwarded resource through the container). Thread replies each get their own block.- Files download into `./lark-im-resources/` under the current working directory. Each distinct `(message_id, file_key)` is downloaded once (deduped) with bounded concurrency (up to 3 in flight).- **Fail-silent isolation**: a single resource that fails to download is flagged `"error": true` with one stderr line (`warning: resource_download_failed: <message_id>/<key>: ...`); the main message and the other resources are unaffected.

After one user confirmation, the interactive-card listener continuously processes callbacks. Events include the operator, submitted values, update token, and original card content, and can be used to replace the complete card.

View source
references/lark-im-card-action-reply.md:31In the instructions
| `type` | string | Always `card.action.trigger` || `event_id` | string | Unique event ID; safe for deduplication || `timestamp` | string (timestamp_ms) | Event delivery time (ms since epoch) || `operator_id` | string (open_id) | Open ID of the user who interacted || `message_id` | string (message_id) | Message ID of the card (`om_xxx`) || `chat_id` | string (chat_id) | Chat ID (`oc_xxx`) || `host` | string | `im_message` (chat card) or `im_top_notice` (top banner) || `token` | string | Delayed-update token; valid 30 min, max 2 uses || `action_tag` | string | Component type that was triggered (see decision table) || `action_value` | string | Developer-defined value on the component; serialized to JSON string || `action_name` | string | `name` attribute of the component || `timezone` | string | User timezone, e.g. `Asia/Shanghai`; only populated for date/time picker interactions || `form_value` | string (JSON) | All form field values as JSON string, keyed by component `name`; only present when a button inside a form container is clicked || `input_value` | string | Input text; only for standalone `input` components (not inside a form) || `option` | string | Selected value for standalone single-select: `select_static`, `select_person`, `overflow`, `date_picker`, `picker_time`, `picker_datetime` || `options` | string | Comma-separated selected values for standalone multi-select: `multi_select_static`, `multi_select_person` || `checked` | bool | Checkbox state for standalone `checker` elements || `card_content` | string | Original card content (userDSL text format) from when the card was sent; auto-fetched via message get API at consume time; empty if `message_id` absent or fetch fails — skip if empty |
references/lark-im-card-action-reply.md:95In the instructions
Only enter the auto-update workflow below if the user confirms. If your runtime does notsupport background monitoring, inform the user that automatic card updates are not availableand they will need to handle interactions manually.## Agent workflowWhen a `card.action.trigger` event arrives (**each stdout JSON line is one event — process it immediately**):
Start here · InstructionsSKILL.md
lark-im
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 40
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records61 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • references/card/lark-im-card-create.mdFull text included
  • references/lark-im-card-action-reply.mdFull text included
  • references/lark-im-chat-create.mdFull text included
  • references/lark-im-chat-list.mdFull text included
  • references/lark-im-chat-members-list.mdFull text included
  • references/lark-im-chat-messages-list.mdFull text included
  • references/lark-im-chat-search.mdFull text included
  • references/lark-im-chat-update.mdFull text included
  • references/lark-im-feed-group-list-item.mdFull text included
  • references/lark-im-feed-group-list.mdFull text included
  • references/lark-im-feed-group-query-item.mdFull text included
  • references/lark-im-feed-groups.mdFull text included
  • references/lark-im-feed-shortcut-create.mdFull text included
  • references/lark-im-feed-shortcut-list.mdFull text included
  • references/lark-im-feed-shortcut-remove.mdFull text included
  • references/lark-im-flag-cancel.mdFull text included
  • references/lark-im-flag-create.mdFull text included
  • references/lark-im-flag-list.mdFull text included
  • references/lark-im-message-enrichment.mdFull text included
  • references/lark-im-message-read-status.mdFull text included
  • references/lark-im-messages-edit.mdFull text included
  • references/lark-im-messages-mget.mdFull text included
  • references/lark-im-messages-reply.mdFull text included
  • references/lark-im-messages-resources-download.mdFull text included
  • references/lark-im-messages-search.mdFull text included
  • references/lark-im-messages-send.mdFull text included
  • references/lark-im-reactions.mdFull text included
  • references/lark-im-threads-messages-list.mdFull text included
  • references/card/components/button.mdFull text included
  • references/card/components/chart.mdFull text included
  • references/card/components/checker.mdFull text included
  • references/card/components/collapsible_panel.mdFull text included
  • references/card/components/column_set.mdFull text included
  • references/card/components/date_picker.mdFull text included
  • references/card/components/div.mdFull text included
  • references/card/components/form.mdFull text included
  • references/card/components/header.mdFull text included
  • references/card/components/hr.mdFull text included
  • references/card/components/img_combination.mdFull text included
  • references/card/components/img.mdFull text included
  • references/card/components/input.mdFull text included
  • references/card/components/interactive_container.mdFull text included
  • references/card/components/markdown.mdFull text included
  • references/card/components/multi_select_person.mdFull text included
  • references/card/components/multi_select_static.mdFull text included
  • references/card/components/overflow.mdFull text included
  • references/card/components/person_list.mdFull text included
  • references/card/components/person.mdFull text included
  • references/card/components/picker_datetime.mdFull text included
  • references/card/components/picker_time.mdFull text included
  • references/card/components/recycling_container.mdFull text included
  • references/card/components/select_img.mdFull text included
  • references/card/components/select_person.mdFull text included
  • references/card/components/select_static.mdFull text included
  • references/card/components/table.mdFull text included
  • references/lark-im-chat-identity.mdFull text included
  • references/card/card-2.0-schema.mdFull text included
  • references/card/lark-im-card-style.mdFull text included
  • references/card/resource/colors.mdFull text included
  • references/card/resource/icons.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • references/card/card-2.0-schema.mdSupporting file
  • references/card/components/button.mdSupporting file
  • references/card/components/chart.mdSupporting file
  • references/card/components/checker.mdSupporting file
  • references/card/components/collapsible_panel.mdSupporting file
  • references/card/components/column_set.mdSupporting file
  • references/card/components/date_picker.mdSupporting file
  • references/card/components/div.mdSupporting file
  • references/card/components/form.mdSupporting file
  • references/card/components/header.mdSupporting file
  • references/card/components/hr.mdSupporting file
  • references/card/components/img.mdSupporting file
  • references/card/components/img_combination.mdSupporting file
  • references/card/components/input.mdSupporting file
  • references/card/components/interactive_container.mdSupporting file
  • references/card/components/markdown.mdSupporting file
  • references/card/components/multi_select_person.mdSupporting file
  • references/card/components/multi_select_static.mdSupporting file
  • references/card/components/overflow.mdSupporting file
  • references/card/components/person.mdSupporting file
  • references/card/components/person_list.mdSupporting file
  • references/card/components/picker_datetime.mdSupporting file
  • references/card/components/picker_time.mdSupporting file
  • references/card/components/recycling_container.mdSupporting file
  • references/card/components/select_img.mdSupporting file
  • references/card/components/select_person.mdSupporting file
  • references/card/components/select_static.mdSupporting file
  • references/card/components/table.mdSupporting file
  • references/card/lark-im-card-create.mdSupporting file
  • references/card/lark-im-card-style.mdSupporting file
  • references/card/resource/colors.mdSupporting file
  • references/card/resource/icons.mdSupporting file
  • references/lark-im-card-action-reply.mdSupporting file
  • references/lark-im-chat-create.mdSupporting file
  • references/lark-im-chat-identity.mdSupporting file
  • references/lark-im-chat-list.mdSupporting file
  • references/lark-im-chat-members-list.mdSupporting file
  • references/lark-im-chat-messages-list.mdSupporting file
  • references/lark-im-chat-search.mdSupporting file
  • references/lark-im-chat-update.mdSupporting file
  • references/lark-im-feed-group-list-item.mdSupporting file
  • references/lark-im-feed-group-list.mdSupporting file
  • references/lark-im-feed-group-query-item.mdSupporting file
  • references/lark-im-feed-groups.mdSupporting file
  • references/lark-im-feed-shortcut-create.mdSupporting file
  • references/lark-im-feed-shortcut-list.mdSupporting file
  • references/lark-im-feed-shortcut-remove.mdSupporting file
  • references/lark-im-flag-cancel.mdSupporting file
  • references/lark-im-flag-create.mdSupporting file
  • references/lark-im-flag-list.mdSupporting file
  • references/lark-im-message-enrichment.mdSupporting file
  • references/lark-im-message-read-status.mdSupporting file
  • references/lark-im-messages-edit.mdSupporting file
  • references/lark-im-messages-mget.mdSupporting file
  • references/lark-im-messages-reply.mdSupporting file
  • references/lark-im-messages-resources-download.mdSupporting file
  • references/lark-im-messages-search.mdSupporting file
  • references/lark-im-messages-send.mdSupporting file
  • references/lark-im-reactions.mdSupporting file
  • references/lark-im-threads-messages-list.mdSupporting file

Operations mentioned in code and instructions

Connect to websites
SKILL.md:40In the instructions
Prefer CLI-returned links: use `chat_app_link` to open joined conversations, `message_app_link` to open messages, and `share_link` to invite others to groups. If manually building a joined-conversation AppLink, use `https://<applink_host>/client/chat/open?openChatId=<oc_xxx>`, never `chatId=<oc_xxx>` or `lark://...chat_id=<oc_xxx>`.
SKILL.md:246In the instructions
| `chat.moderation.update` | `im:chat:moderation:write_only` || `chat.join_requests.list` | `im:chat.membership_application:read` || `chat.join_requests.handle` | `im:chat.membership_application:write` |
SKILL.md:247In the instructions
| `chat.join_requests.list` | `im:chat.membership_application:read` || `chat.join_requests.handle` | `im:chat.membership_application:write` || `+messages-read-status` | user: `im:message:readonly` (recommended), `im:message`, or `im:message:get_as_user` |
Run commands
SKILL.md:137In the instructions
```bashlark-cli schema im.<resource>.<method>   # 调用 API 前必须先查看参数结构
references/card/lark-im-card-create.md:101In the instructions
```bash# 发送到群聊
references/lark-im-card-action-reply.md:89In the instructions
Once the listener is running, check whether your agent runtime supports background eventmonitoring (i.e. can receive and process stdout lines from a running subprocess whilecontinuing to respond to the user). If it does, prompt the user:
Read files
references/lark-im-messages-edit.md:45In the instructions
- **`--set-attachments` is a replace, not an append:** the flag values become the final `files` array. Send/reply's `--attachment` merges; edit's `--set-attachments` replaces.- **Mutually exclusive with `--content` carrying files:** when `--content` already contains a `files` array, `--set-attachments` and `--clear-attachments` are rejected — declare the attachment zone either via `--content` or via the attachment flags, not both. Use `--markdown` (which never emits a `files` array) or a `--content` without `files` together with the attachment flags.- The server fills name/size/mime/is_folder from file service metadata; the client does not (and cannot) override the display name.
references/lark-im-messages-send.md:200In the instructions
> **Mutual exclusivity rule:** `--text`, `--markdown`, `--content`, and `--image`/`--file`/`--video`/`--audio` cannot be used together. Media flags are also mutually exclusive with each other. `--attachment` cannot be combined with a `--content` that already contains a `files` array (the attachment zone is declared either via `--content` or via `--attachment`, not both).>
Lines read
5,891
File checksum (to compare versions)
31d3ede3d82e8b90938338a26b69af35abe077e6d795b92d03329a700048c771