@yandy0725/pi-lark 0.1.0

package/skills/lark-im/references/lark-im-feed-shortcut-remove.md

@@ -0,0 +1,48 @@
+# im +feed-shortcut-remove
+
+> **Prerequisite:** Read [`../lark-shared/SKILL.md`](../../lark-shared/SKILL.md) for authentication, global parameters, and security rules.
+
+This skill maps to shortcut: `lark-cli im +feed-shortcut-remove`. Underlying API: `POST /open-apis/im/v2/feed_shortcuts/remove`.
+
+## What it does
+
+Removes one or more chats from the **current user's** feed shortcuts.
+
+- Only **CHAT-type** shortcuts are supported (`feed_card_id` must be an `oc_xxx`).
+- Batch up to **10 chat IDs per call**.
+- Currently only supports **user identity** (`--as user`).
+- Removing a chat that is not currently in the shortcut list is idempotent success: the call returns `ok:true`, `failure_count=0`, and no `failed_shortcuts` entry for that chat.
+
+## Commands
+
+```bash
+# Remove a single feed shortcut
+lark-cli im +feed-shortcut-remove --as user --chat-id oc_xxx
+
+# Remove multiple feed shortcuts in one call
+lark-cli im +feed-shortcut-remove --as user --chat-id oc_a,oc_b
+lark-cli im +feed-shortcut-remove --as user --chat-id oc_a --chat-id oc_b
+
+# Preview the request
+lark-cli im +feed-shortcut-remove --as user --chat-id oc_xxx --dry-run
+```
+
+## Parameters
+
+| Parameter | Required | Description |
+|------|------|------|
+| `--chat-id <oc_xxx>` | yes | open_chat_id to remove from feed shortcuts; repeatable or comma-separated; max 10 per call |
+| `--as user` | yes | Server only accepts user_access_token for this API |
+
+## Response
+
+The response uses the same batch ledger as [`+feed-shortcut-create`](lark-im-feed-shortcut-create.md#response): `total`, `success_count`, `failure_count`, `succeeded_shortcuts`, and `failed_shortcuts`. A non-empty `failed_shortcuts` is a partial failure: stdout carries `ok:false` with the full ledger and the process exits non-zero (currently exit `1`).
+
+## Permissions
+
+- Required scope: `im:feed.shortcut:write`
+- Only available with user identity (`--as user`).
+
+## Note
+
+- To see what is currently in the shortcut list before removing, run [`+feed-shortcut-list`](lark-im-feed-shortcut-list.md). Use `--no-detail` when you only need the `feed_card_id` values.

package/skills/lark-im/references/lark-im-flag-cancel.md

@@ -0,0 +1,67 @@
+# im +flag-cancel
+
+> **Prerequisite:** Read [`../lark-shared/SKILL.md`](../../lark-shared/SKILL.md) for authentication, global parameters, and security rules.
+
+This skill maps to shortcut: `lark-cli im +flag-cancel`. Underlying API: `POST /open-apis/im/v1/flags/cancel`.
+
+## Double-Cancel Behavior (Important)
+
+A message can have flags on both layers simultaneously:
+- Message layer: `(default, message)`
+- Feed layer: `(thread, feed)` or `(msg_thread, feed)` depending on chat type
+
+**When no `--flag-type` is specified, the shortcut performs best-effort double-cancel**: the message-layer flag is always removed; the feed-layer flag is also removed when the chat type can be determined (otherwise a warning is printed on stderr and the feed layer is skipped). The server handles cancel requests for non-existent flags idempotently, so this is safe.
+
+**Feed layer item_type is determined by chat_mode**:
+- Topic-style chat (`chat_mode=topic`) → `item_type=thread`
+- Regular chat (`chat_mode=group`) → `item_type=msg_thread`
+
+## Commands
+
+```bash
+# Double-cancel both layers (recommended default)
+lark-cli im +flag-cancel --as user --message-id om_xxx
+
+# Only cancel message layer
+lark-cli im +flag-cancel --as user --message-id om_xxx --flag-type message
+
+# Only cancel feed layer (need to specify item-type)
+lark-cli im +flag-cancel --as user --message-id om_xxx --item-type thread --flag-type feed
+
+# Preview request
+lark-cli im +flag-cancel --as user --message-id om_xxx --dry-run
+```
+
+## Parameters
+
+| Parameter | Required | Description |
+|------|------|------|
+| `--message-id <om_xxx>` | Required | Message ID |
+| `--flag-type <name>` | No | `message` or `feed`; **when omitted, best-effort double-cancel of both layers** |
+| `--item-type <name>` | No | `default\|thread\|msg_thread`; required when `--flag-type feed` |
+| `--as user` | Required | Currently only supports user identity |
+
+## Idempotency
+
+The server doesn't return an error for cancel requests when the flag doesn't exist, so repeated `+cancel` calls are idempotent.
+
+## Permissions
+
+- Required scopes: `im:feed.flag:write`, `im:message.group_msg:get_as_user`, `im:message.p2p_msg:get_as_user`, `im:chat:read`
+- The message/chat read scopes are used by the default double-cancel path to auto-detect the feed-layer item type.
+
+## Note
+
+- **Do not call +flag-list for verification**: If the cancel API returns success, the flag is removed. Calling +flag-list to verify is expensive (requires full pagination) and unnecessary.
+
+## Finding Message ID Efficiently
+
+If you have message content but not the message ID:
+
+1. **Use `+messages-search`** to find the message by content, then extract `message_id` from the result
+2. **Do NOT use `+flag-list`** to find the message — it requires full pagination and is very inefficient
+
+```bash
+# Search by message content to find message_id
+lark-cli im +messages-search --as user --query "message content here" -q '.data.items[0].message_id'
+```

package/skills/lark-im/references/lark-im-flag-create.md

@@ -0,0 +1,67 @@
+# im +flag-create
+
+> **Prerequisite:** Read [`../lark-shared/SKILL.md`](../../lark-shared/SKILL.md) for authentication, global parameters, and security rules.
+
+This skill maps to shortcut: `lark-cli im +flag-create`. Underlying API: `POST /open-apis/im/v1/flags`.
+
+## Default Behavior
+
+- **Message-layer flag** (default): `item_type=default, flag_type=message`
+- **Feed-layer flag**: Use `--flag-type feed` — automatically detects chat type to determine `item_type`:
+  - Topic-style chat (`chat_mode=topic`) → `item_type=thread`
+  - Regular chat (`chat_mode=group`) → `item_type=msg_thread`
+
+## Commands
+
+```bash
+# Flag a message (default: message-layer)
+lark-cli im +flag-create --as user --message-id om_xxx
+
+# Create feed-layer flag (auto-detects chat type)
+lark-cli im +flag-create --as user --message-id om_xxx --flag-type feed
+
+# Explicit item-type override (rarely needed)
+lark-cli im +flag-create --as user --message-id om_xxx --item-type thread --flag-type feed
+
+# Preview request (dry-run, doesn't send)
+lark-cli im +flag-create --as user --message-id om_xxx --dry-run
+```
+
+## Parameters
+
+| Parameter | Required | Description |
+|------|------|------|
+| `--message-id <om_xxx>` | Required | Message ID |
+| `--flag-type <name>` | No | `message` (default) or `feed` |
+| `--item-type <name>` | No | Override auto-detection: `default\|thread\|msg_thread` (rarely needed) |
+| `--as user` | Required | Currently only supports user identity |
+
+## Valid Combinations
+
+The server only accepts these `(item_type, flag_type)` pairs:
+
+- `(default, message)` — regular message flag
+- `(thread, feed)` — feed flag in topic-style chat
+- `(msg_thread, feed)` — feed flag in regular chat
+
+## Permissions
+
+- Required scopes: `im:feed.flag:write`, `im:message.group_msg:get_as_user`, `im:message.p2p_msg:get_as_user`, `im:chat:read`
+- The message/chat read scopes are used when `--flag-type feed` is used without explicit `--item-type` so the CLI can auto-detect chat type.
+- If missing, CLI will prompt with `lark-cli auth login --scope "..."`
+
+## Note
+
+- **Do not call +flag-list for verification**: If the create API returns success, the flag is created. Calling +flag-list to verify is expensive (requires full pagination) and unnecessary.
+
+## Finding Message ID Efficiently
+
+If you have message content but not the message ID:
+
+1. **Use `+messages-search`** to find the message by content, then extract `message_id` from the result
+2. **Do NOT use `+flag-list`** to find the message — it requires full pagination and is very inefficient
+
+```bash
+# Search by message content to find message_id
+lark-cli im +messages-search --as user --query "message content here" -q '.data.items[0].message_id'
+```

package/skills/lark-im/references/lark-im-flag-list.md

@@ -0,0 +1,100 @@
+# im +flag-list
+
+> **Prerequisite:** Read [`../lark-shared/SKILL.md`](../../lark-shared/SKILL.md) for authentication, global parameters, and security rules.
+
+This skill maps to shortcut: `lark-cli im +flag-list`. Underlying API: `GET /open-apis/im/v1/flags`.
+
+## Sorting Rules (Important)
+
+The API returns data sorted by `update_time` in **ascending order**, meaning **oldest first, newest last**. When `has_more=true`, you cannot simply take the first page's items as the latest flags — you must paginate through all pages and take the last item on the last page as the newest.
+
+Recommended: use `--page-all` for auto-pagination to get the complete list, then use `-q '.data.flag_items[-1]'` to get the latest item.
+
+## Commands
+
+```bash
+# Fetch first page (default page-size=50)
+lark-cli im +flag-list --as user
+
+# Manual pagination with custom page size
+lark-cli im +flag-list --as user --page-size 30 --page-token <page_token>
+
+# Auto-paginate to get all flags (recommended)
+lark-cli im +flag-list --as user --page-all
+
+# Auto-paginate + get the latest flag
+lark-cli im +flag-list --as user --page-all -q '.data.flag_items[-1]'
+
+# Auto-paginate + get only item_id list
+lark-cli im +flag-list --as user --page-all -q '.data.flag_items[].item_id'
+
+# Disable auto-enrichment of message content (enabled by default)
+lark-cli im +flag-list --as user --page-all --enrich-feed-thread=false
+
+# Limit max pages (default 20, max 1000)
+lark-cli im +flag-list --as user --page-all --page-limit 10
+```
+
+## Parameters
+
+| Parameter | Default | Description |
+|------|------|------|
+| `--page-size <n>` | 50 | Range 1-50 (server max is 50) |
+| `--page-token <token>` | empty | Pagination token from previous page; empty string must still be provided |
+| `--page-all` | false | Auto-paginate to fetch all pages and merge results |
+| `--page-limit <n>` | 20 | Max pages in `--page-all` mode (max 1000) |
+| `--enrich-feed-thread` | true | Auto-enrich feed-layer thread entries with message content (calls `im.messages.mget`) |
+| `--as user` | Required | Currently only supports user identity |
+
+## Response Structure
+
+The response has `data` as the main body, with fields described below:
+
+| Field | Type | Description |
+|------|------|------|
+| `flag_items` | array | List of currently existing (not canceled) flags, sorted by `update_time` ascending |
+| `delete_flag_items` | array | List of previously canceled flags, sorted by `update_time` ascending |
+| `messages` | array | Message content inlined by the server for `(default, message)` type flags |
+| `has_more` | boolean | Whether there's a next page |
+| `page_token` | string | Pagination token for the next page |
+
+Note: `(thread, feed)` / `(msg_thread, feed)` entries are automatically enriched via `mget` by the shortcut, and written to the corresponding entry's `message` field.
+
+## Limitations
+
+- **delete_flag_items are not enriched**: Message content is only fetched for active flags (`flag_items`), not canceled flags (`delete_flag_items`). If you need message content for a canceled flag, query the message separately using `+messages-mget --message-ids <item_id>`.
+
+## Response Example (Sanitized)
+
+```json
+{
+  "data": {
+    "delete_flag_items": [
+      {
+        "create_time": "xxx",
+        "flag_type": "xxx",
+        "item_id": "xxx",
+        "item_type": "xxx",
+        "update_time": "xxx"
+      }
+    ],
+    "flag_items": [
+      {
+        "create_time": "xxx",
+        "flag_type": "xxx",
+        "item_id": "xxx",
+        "item_type": "xxx",
+        "update_time": "xxx"
+      }
+    ],
+    "has_more": false,
+    "messages": [],
+    "page_token": "xxx"
+  }
+}
+```
+
+## Permissions
+
+- Base scope: `im:feed.flag:read`
+- Additional scopes only when `--enrich-feed-thread=true` needs to fetch missing message content: `im:message.group_msg:get_as_user`, `im:message.p2p_msg:get_as_user`

package/skills/lark-im/references/lark-im-message-enrichment.md

@@ -0,0 +1,54 @@
+# im default message enrichment (reactions / update_time)
+
+> **Prerequisite:** Read [`../lark-shared/SKILL.md`](../../lark-shared/SKILL.md) first to understand authentication, global parameters, and safety rules.
+
+This is the single source of truth for the automatic message-enrichment contract shared by the four message-pulling shortcuts — [`+messages-mget`](lark-im-messages-mget.md), [`+chat-messages-list`](lark-im-chat-messages-list.md), [`+messages-search`](lark-im-messages-search.md), [`+threads-messages-list`](lark-im-threads-messages-list.md). They automatically attach `reactions` and `update_time` to each returned message, so callers do **not** need to invoke the raw [`im.reactions.batch_query`](lark-im-reactions.md) API separately.
+
+- **`reactions`** — populated from `im.reactions.batch_query` as `{counts, details}`. The field is only attached when the server actually returns data; messages with no reactions omit it. Replies inside `thread_replies` are enriched alongside their parent (collected into the same id set), so outer and inner messages follow identical semantics. The id set is split into batches of <= 20 (server-side cap) and the batches are dispatched with bounded concurrency (up to 4 in flight), so high-N pulls — e.g. page 50 + ~500 expanded thread replies = 550 ids → ⌈550 / 20⌉ = **28 batches** — finish in a few round-trips instead of serializing into tens of seconds.
+- **`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.
+
+## Thread replies expansion
+
+`+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.
+
+`totalLimit` is enforced **post-fetch against actual returned reply counts**, not against the planned per-thread ceiling — so a chat with many short threads (e.g. 12 threads × 3 actual replies = 36 ≪ 500) attaches every thread, even though the planned sum (12 × 50 = 600) would exceed the budget. When a thread's actual replies push the running total across `totalLimit`, that thread is truncated to fit the remaining budget and its host is flagged with `thread_has_more: true` so consumers know the server has more.
+
+On per-thread fetch failure the host gets `thread_replies_error: true` (mirrors the reactions data contract); budget-truncated or budget-skipped threads do NOT carry that flag.
+
+## Resource auto-download (`--download-resources`, opt-in)
+
+`+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.
+- Output paths are confined to `./lark-im-resources/` by the same guards as [`+messages-resources-download`](lark-im-messages-resources-download.md) (abnormal `file_key` with path separators / `..` / absolute paths is rejected).
+- **Scope**: the download uses `GET /open-apis/im/v1/messages/:message_id/resources/:file_key`, which requires `im:message:readonly` — already declared in each listing command's `Scopes`, so `--download-resources` needs **no extra scope** beyond what's required to read the messages (user identity also needs `im:message.group_msg:get_as_user` / `im:message.p2p_msg:get_as_user`; bot identity needs `im:message.group_msg` / `im:message.p2p_msg:readonly`, all already declared). Works under both user and bot identity. If a bot was registered before `im:message:readonly` was granted, a single resource will fail-silently (`error: true` + stderr warning) rather than aborting the pull.
+
+Use `--download-resources` when you want the binaries on disk in one pass; otherwise the message content keeps the inline resource markers (e.g. `![Image](img_xxx)`, `<file .../>`, `<audio key="..." duration="Xs"/>`) and you can fetch individual resources later with [`+messages-resources-download`](lark-im-messages-resources-download.md).
+
+## Scope requirement
+
+The default enrichment requires `im:message.reactions:read`, already declared in each shortcut's `UserScopes` / `BotScopes` (or `Scopes` for the user-only search command), so the framework's pre-flight check surfaces a `missing_scope` error before the request is sent. Bots that were registered before this scope was added need an incremental authorization in the Feishu developer console; users can run:
+
+```bash
+lark-cli auth login --scope "im:message.reactions:read"
+```
+
+## Data contract — missing field ≠ fetch failure
+
+| Situation | Output |
+|---|---|
+| Message has no reactions | `reactions` field is omitted (not `{}`, not an empty list) |
+| Message was never edited | `update_time` field is omitted |
+| Whole batch failed | Messages in that batch carry no `reactions`; one line on stderr: `warning: reactions_batch_query_failed: ...` |
+| Some message IDs failed | Failed IDs go to stderr: `warning: reactions_partial_failed: N message(s) failed (...)` |
+
+When deciding "has the user already reacted?", branch on the **presence of the `reactions` field plus its `counts` contents**, not on whether a value is `null` — the field's absence means "no data attached" (which usually means "no reactions exist"), not "fetch failed".

package/skills/lark-im/references/lark-im-messages-mget.md

@@ -0,0 +1,99 @@
+# im +messages-mget
+
+> **Prerequisite:** Read [`../lark-shared/SKILL.md`](../../lark-shared/SKILL.md) first to understand authentication, global parameters, and safety rules.
+
+Fetch message details in batch. Given a list of message IDs, this returns the full content for multiple messages in one call and automatically resolves sender names.
+
+By default the response also carries a `reactions` block (counts + details from `im.reactions.batch_query`) on every message that has reactions, and `update_time` on messages that were actually edited. Replies inside `thread_replies` participate in the same batched enrichment. Pass `--no-reactions` to skip the extra round-trip. Pass `--download-resources` to additionally download message resources (image/file/audio/video/media + post-embedded, excluding stickers) into `./lark-im-resources/` and attach a `resources` block — off by default, no extra requests when omitted. See [message enrichment](lark-im-message-enrichment.md) for the full contract.
+
+> **Supports both `--as user` (default) and `--as bot`.**
+
+This skill maps to the shortcut: `lark-cli im +messages-mget` (internally calls `GET /open-apis/im/v1/messages/mget`).
+
+## Commands
+
+```bash
+# Fetch a single message
+lark-cli im +messages-mget --message-ids om_xxx
+
+# Fetch multiple messages in batch (comma-separated)
+lark-cli im +messages-mget --message-ids "om_aaa,om_bbb,om_ccc"
+
+# JSON output
+lark-cli im +messages-mget --message-ids "om_aaa,om_bbb" --format json
+
+# Preview the request without executing it
+lark-cli im +messages-mget --message-ids "om_aaa" --dry-run
+```
+
+## Parameters
+
+| Parameter | Required | Limits | Description |
+|------|------|------|------|
+| `--message-ids <ids>` | Yes | At least one, max 50, `om_xxx` format, comma-separated | Message ID list |
+| `--no-reactions` | No | — | Skip auto-fetching the `reactions` block |
+| `--download-resources` | No | — | Download message resources (image/file/audio/video/media + post-embedded, excluding stickers) into `./lark-im-resources/` and attach a `resources` block. Off by default |
+
+## Output Fields
+
+| Field | Description |
+|------|------|
+| `messages` | Message array |
+| `total` | Number of messages returned |
+
+Each message contains:
+
+| Field | Description |
+|------|------|
+| `message_id` | Message ID |
+| `msg_type` | Message type (`text`, `image`, `file`, etc.) |
+| `create_time` | Creation time |
+| `sender` | Sender information (includes `name`) |
+| `content` | Message content |
+
+## Usage Scenarios
+
+### Scenario 1: Fetch the full content of a specific message
+
+```bash
+lark-cli im +messages-mget --message-ids om_xxx --format json
+```
+
+### Scenario 2: Fetch multiple messages in one batch
+
+```bash
+lark-cli im +messages-mget --message-ids "om_aaa,om_bbb,om_ccc"
+```
+
+### Scenario 3: Use together with the message list command
+
+First get message IDs via `+chat-messages-list`, then fetch full content via `+messages-mget`:
+
+```bash
+# Get the message list
+lark-cli im +chat-messages-list --chat-id oc_xxx --format json
+
+# Fetch specific message details
+lark-cli im +messages-mget --message-ids "om_aaa,om_bbb"
+```
+
+## Common Errors and Troubleshooting
+
+| Symptom | Root Cause | Solution |
+|---------|---------|---------|
+| `--message-ids requires at least one message ID` | No message ID was provided | Provide at least one message ID |
+| `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 |
+
+## AI Usage Guidance
+
+1. **Use JSON for full content:** table output truncates content. Use `--format json` when the full body matters.
+2. **Sender names are already enriched:** the command resolves sender names automatically, so no extra lookup is required.
+3. **Images are rendered as placeholders:** image messages appear as placeholders such as `![Image](img_xxx)`. Use `+messages-resources-download` when you need the binary resource.
+4. **Batching is more efficient:** fetching multiple IDs in one request is better than calling the API repeatedly.
+
+## References
+
+- [lark-im](../SKILL.md) - all IM commands
+- [lark-shared](../../lark-shared/SKILL.md) - authentication and global parameters