@amaster.ai/pi-lark 0.1.4 → 0.1.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@amaster.ai/pi-lark",
-  "version": "0.1.4",
+  "version": "0.1.6",
   "description": "Pi extension for Lark/Feishu workspace — calendar, docs, drive, sheets, tasks, mail and more via lark-cli.",
   "keywords": [
     "pi-package",
@@ -56,12 +56,12 @@
     }
   },
   "devDependencies": {
-    "@earendil-works/pi-coding-agent": "0.74.0",
+    "@earendil-works/pi-coding-agent": "0.80.10",
     "typebox": "*",
     "vitest": "^4.0.0"
   },
   "dependencies": {
-    "@amaster.ai/pi-shared": "0.1.4"
+    "@amaster.ai/pi-shared": "0.1.6"
   },
   "scripts": {
     "fetch-skills": "node scripts/fetch-skills.mjs",

package/skills/lark-approval/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: lark-approval
+version: 1.2.0
+description: "飞书审批：查询和处理审批待办/已办/实例，搜索可发起审批定义、查看定义详情并发起原生审批实例。当用户要处理审批任务、查看审批实例、搜索或发起审批时使用。审批待办不是飞书任务；非审批类待办走 lark-task。不负责创建审批定义；三方审批定义不走原生提单。"
+metadata:
+  requires:
+    bins: ["lark-cli"]
+  cliHelp: "lark-cli approval --help"
+---
+
+
+**CRITICAL — 开始前 MUST 先用 Read 工具读取 [`../lark-shared/SKILL.md`](../lark-shared/SKILL.md)，其中包含认证、权限处理**
+
+所有命令默认 `--as user`（审批是人的动作）。调用前先按需读取 references 下对应的文件，查参数结构，不要猜字段；**references 是第一信息源**，只有在 reference 未覆盖的原生 / 高级场景下，才额外用 `lark-cli ... --help`、`lark-cli schema` 等方式补充确认字段。
+
+## 路由优先级（先判断是不是审批，再选命令）
+
+审批待办不是飞书任务。**只要用户的核心对象是审批单据 / 审批待办 / 审批实例，就优先使用 `lark-approval`，不要让渡给 `lark-task`。**
+
+### 明确归 `lark-approval` 的高优先级语义
+
+出现以下任一语义时，优先走 `lark-approval`：
+
+- 审批待办 / 审批单据 / 审批实例 / 审批意见 / 审批定义
+- 同意 / 拒绝 / 转交 / 退回 / 撤回 / 催办 / 加签 / 抄送
+- 待办列表 / 待办单据 / 已发起审批 / 已办审批 / 审批详情 / 同意可编辑
+
+**判定规则：** 只要最终动作是对审批单据做同意、拒绝、转交、退回、撤回、催办、加签、抄送、查详情、查已发起/已办/待办，就归 `lark-approval`。只有当用户处理的是**非审批类任务/待办**时，才走 [`lark-task`](../lark-task/SKILL.md)。
+
+## 选哪个命令
+
+| 想做什么 | 命令 | 按需读取 reference                                                                  |
+|---|---|---------------------------------------------------------------------------------|
+| 搜可发起定义 | `approvals search` | [`lark-approval-approvals-search.md`](references/lark-approval-approvals-search.md) |
+| 看审批定义详情/提单前确认表单与流程 | `approvals get` | [`lark-approval-approvals-get.md`](references/lark-approval-approvals-get.md)   |
+| 发起原生审批实例/提交请假审批/提交报销审批/创建审批实例 | `instances create` | [`lark-approval-initiate.md`](references/lark-approval-initiate.md)             |
+| 查待办/已办 | `tasks query`（`topic`：1待办 2已办 17未读 18已读） | [`lark-approval-tasks-query.md`](references/lark-approval-tasks-query.md)       |
+| 看表单/进度/当前节点 | `instances get` | [`lark-approval-instances-get.md`](references/lark-approval-instances-get.md)   |
+| 同意审批 | `tasks approve` | [`lark-approval-tasks-approve.md`](references/lark-approval-tasks-approve.md)   |
+| 拒绝审批 | `tasks reject` | [`lark-approval-tasks-reject.md`](references/lark-approval-tasks-reject.md)     |
+| 转交审批 | `tasks transfer` | [`lark-approval-tasks-transfer.md`](references/lark-approval-tasks-transfer.md) |
+| 加签审批 | `tasks add_sign` | [`lark-approval-tasks-add-sign.md`](references/lark-approval-tasks-add-sign.md) |
+| 退回审批 | `tasks rollback` | [`lark-approval-tasks-rollback.md`](references/lark-approval-tasks-rollback.md) |
+| 催办审批 | `tasks remind` | [`lark-approval-tasks-remind.md`](references/lark-approval-tasks-remind.md)     |
+| 撤回已发起审批 | `instances cancel` | [`lark-approval-instances-cancel.md`](references/lark-approval-instances-cancel.md) |
+| 给审批实例追加抄送 | `instances cc` | [`lark-approval-instances-cc.md`](references/lark-approval-instances-cc.md)     |
+| 按定义查已发起审批 | `instances initiated` | [`lark-approval-instances-initiated.md`](references/lark-approval-instances-initiated.md) |
+
+处理链：
+
+- 发起审批：`approvals search` -> `approvals get` -> `instances create`
+- 处理审批：`tasks query` 拿 `instance_code` + `task_id`（操作必须成对带上）→ 只有用户明确需要查看详情、当前节点、表单内容、或流程进度时，再 `instances get` → 执行操作
+
+## 执行原则（减少误路由、误重试和无效消耗）
+
+### 1) 先拿最小必要信息，再执行
+
+- 目标只是处理待办时，优先 `tasks query` 获取 `instance_code` + `task_id`
+- **只有**用户明确要看详情、当前节点、表单内容、流程进度时，才调用 `instances get`
+- 用户已经明确给出 `instance_code` / `task_id` 时，不要先查列表再过滤
+
+### 2) 已知对象时直达动作
+
+- 已拿到 `instance_code` + `task_id` 后，优先直接执行 `tasks approve/reject/transfer/add_sign/rollback/remind`
+- 同一轮里如果已有足够的新鲜查询结果，不要重复 `tasks query`
+- 不要默认走 `list -> filter -> detail -> write` 全链路；对象已明确时应压缩步骤
+
+### 3) 错误码驱动，而不是盲目重试
+
+- 写操作失败后，先看错误码和报错语义，再决定是否补查或结束
+- **除非错误明确提示可恢复或需要补充参数，否则不要重复刷同一个写操作**
+- 同一个失败原因不要连续多次重试，避免 token 和耗时失控，最多重试1次
+
+## 写操作失败处理：1395001 决策树
+
+当拒绝 / 转交 / 退回 / 撤回 / 同意等写操作返回 `1395001`（任务状态异常 / 写前置校验失败）时，按下面规则处理：
+
+1. **先停止盲目重试**，不要连续重复提交相同写操作，最多重试1次
+2. 优先从以下角度解释：
+   - 任务可能已被他人处理
+   - 单据状态已变化，当前动作已不再允许
+   - 当前用户已不具备该任务的操作资格
+   - 当前节点或单据状态不支持该操作
+3. 如需确认，只补 **一次** 状态查询（`tasks query` 或 `instances get`），不要陷入 query/write 循环
+4. 最终给用户明确结论和下一步建议，而不是继续无意义重试
+
+**特别注意：** 对拒绝 / 转交 / 撤回场景更要严格执行上述规则；这些场景最容易因状态切换而失败。
+
+```bash
+lark-cli approval approvals search --data '{"keyword":"请假"}' --as user
+lark-cli approval approvals get --params '{"approval_code":"<code>"}' --as user
+lark-cli approval instances create --data '{"approval_code":"<code>","form":"[...]"}' --yes --as user
+lark-cli approval tasks query --params '{"topic":"1"}' --as user
+lark-cli approval tasks approve --data '{"instance_code":"<ic>","task_id":"<tid>","comment":"同意"}' --as user
+```
+
+## 不在本 skill 范围
+
+创建审批定义（走飞书客户端或审批管理后台）；三方定义发起（返回 `create_link`，引导用户通过链接发起）；非审批类待办 → [`lark-task`](../lark-task/SKILL.md)

package/skills/lark-approval/references/lark-approval-approvals-get.md

@@ -0,0 +1,128 @@
+
+# approval approvals get
+
+获取单个审批定义详情（用户级只读操作）。适合在发起审批实例前，先确认审批名称、表单控件结构、选项值范围以及流程节点信息。
+
+需要的 scopes: ["approval:approval:read"]
+
+## 命令
+
+```bash
+# 按 approval_code 查询审批定义详情
+lark-cli approval approvals get --params '{"approval_code":"<APPROVAL_CODE>"}' --as user
+
+# 表格格式输出，便于快速浏览顶层字段
+lark-cli approval approvals get --params '{"approval_code":"<APPROVAL_CODE>"}' --format table --as user
+
+# 预览 API 调用，不执行
+lark-cli approval approvals get --params '{"approval_code":"<APPROVAL_CODE>"}' --as user --dry-run
+```
+
+## 参数
+
+| 参数 | 必填 | 说明 |
+|------|------|------|
+| `--params '{...}'` | 是 | 查询参数，使用 JSON 传入 |
+| `approval_code` | 是 | 审批定义 Code；通常来自 `approval approvals search` 的结果 |
+| `locale` | 否 | 返回语言，例如 `zh-CN`、`en-US`、`ja-JP` |
+| `--as user` | 否 | 建议显式指定用户身份；审批定义详情通常按当前用户可见范围读取 |
+| `--format` | 否 | 输出格式：`json`（默认）、`ndjson`、`table`、`csv` |
+| `--dry-run` | 否 | 预览 API 调用，不执行 |
+
+## 常见输入来源
+
+如果你已经有 `approval_code`，可直接查询：
+
+```bash
+lark-cli approval approvals get --params '{"approval_code":"<APPROVAL_CODE>"}' --as user
+```
+
+如果你还没有 `approval_code`，先搜索可发起审批定义：
+
+```bash
+lark-cli approval approvals search --data '{"keyword":"请假"}' --as user
+```
+
+## 输出重点字段
+
+返回结果中，优先关注以下字段：
+
+| 字段 | 说明 |
+|------|------|
+| `approval_code` | 审批定义 Code |
+| `approval_name` | 审批定义名称；确认是不是用户想发起的那张单 |
+| `form` | 表单定义快照；用于识别控件 `id`、`type`、选项值范围、明细子控件结构 |
+| `node_list` | 流程节点列表；用于识别节点 key、是否需要补充审批人、是否允许多人 |
+
+## form 的使用重点
+
+`form` 最重要的作用是帮助 agent **识别怎么组装 `instances.create.data.form`**，而不是直接把它原样提交出去。
+
+重点看：
+
+| 字段 / 结构 | 说明 |
+|------|------|
+| `form[].id` | 控件 ID；后续创建实例时必须使用 |
+| `form[].type` | 控件类型，例如 `input`、`date`、`radio`、`checkbox`、`fieldList` |
+| `form[].value` / 选项定义 | 用来识别可选值范围、默认值或选项值 |
+| 明细 / 子控件结构 | 用于识别 `fieldList`、控件组等复杂控件的子字段结构 |
+
+**注意：`approvals.get.form` 不是 `instances.create` 可直接复用的 payload 模板。** 它是“定义快照”，主要用于识别字段结构与选项值范围。
+
+## node_list 的使用重点
+
+`node_list` 主要用于后续决定是否要补 `node_approver_list` / `node_cc_list`。
+
+重点看：
+
+| 字段 | 说明 |
+|------|------|
+| `node_list[].custom_node_id` | 自定义节点标识；后续补节点参数时优先作为 key |
+| `node_list[].node_id` | 节点 ID；若没有 `custom_node_id`，通常退回用它做 key |
+| `node_list[].need_approver` | 是否要求发起人补充审批人 |
+| `node_list[].approver_chosen_multi` | 是否允许为该节点选择多个审批人 |
+
+## 使用建议
+
+- **这是发起原生审批实例前的必要只读步骤。** 推荐固定走：`approvals search` -> `approvals get` -> `instances create`。
+- **如果用户已经明确给了 `approval_code`，直接用这个命令。** 不必再走 `approvals search`。
+- **先确认 `approval_name`。** 避免把相似名称的审批定义搞混。
+- **先用 `form` 识别控件结构，再组装创建 payload。** 不要在未看详情时猜控件 `id`、`type` 或选项值。
+- **先用 `node_list` 看是否需要补审批人。** 若某节点 `need_approver=true`，创建实例时通常要补 `node_approver_list`。
+- **`node_list` 的 key 优先取 `custom_node_id`。** 若不存在，再使用 `node_id`。
+- **`approver_chosen_multi=false` 时，一个节点通常只能补一个审批人。**
+
+## 输出与后续操作
+
+读取定义详情后，常见下一步：
+
+```bash
+# 发起原生审批实例
+lark-cli approval instances create --data '{"approval_code":"<APPROVAL_CODE>","form":"[...]"}' --as user --yes
+```
+
+如果需要进一步理解控件取值与节点参数，优先参考：
+
+- `lark-approval-instance-form-control-parameters.md`
+- `lark-approval-instance-value-sourcing.md`
+- `lark-approval-initiate.md`
+
+## 结果整理方式
+
+**将结果整理为“审批定义概览 + 表单结构摘要 + 节点要求摘要”。**
+
+建议输出成下面这种结构：
+
+```text
+审批定义：请假申请
+approval_code: 7C468A54-8745-2245-9675-08B7C63E7A85
+
+表单控件摘要：
+- leave_type: radio，可选值 [annual_leave, sick_leave]
+- reason: textarea
+- start_end: dateInterval
+
+节点要求摘要：
+- manager_node：need_approver=true，approver_chosen_multi=false
+- hr_node：need_approver=false
+```

package/skills/lark-approval/references/lark-approval-approvals-search.md

@@ -0,0 +1,103 @@
+
+# approval approvals search
+
+搜索**当前用户可发起**的审批定义（launchable approvals）。只读操作，不会创建审批实例。
+
+需要的 scopes: ["approval:approval:read"]
+
+## 命令
+
+```bash
+# 按关键词搜索可发起审批定义
+lark-cli approval approvals search --data '{"keyword":"请假"}' --as user
+
+# 使用 page_token 翻页
+lark-cli approval approvals search --data '{"keyword":"请假", "page_token":"example_page_token"}' --as user
+
+# 表格格式输出，便于快速浏览候选定义
+lark-cli approval approvals search --data '{"keyword":"出差"}' --format table --as user
+
+# 预览 API 调用，不执行
+lark-cli approval approvals search --data '{"keyword":"请假"}' --as user --dry-run
+```
+
+## 参数
+
+| 参数 | 必填 | 说明 |
+|------|------|------|
+| `--data '{...}'` | 是 | 查询参数，使用 JSON 传入 |
+| `keyword` | 是 | 搜索关键词，例如 `请假`、`报销`、`出差`、`采购` |
+| `locale` | 否 | 返回语言，例如 `zh-CN`、`en-US`、`ja-JP` |
+| `page_size` | 否 | 分页大小 |
+| `page_token` | 否 | 翻页标记；首次请求不填，后续使用上一次返回的 `page_token` |
+| `--as user` | 否 | 建议显式指定用户身份；“可发起审批定义”是面向当前用户的查询 |
+| `--format` | 否 | 输出格式：`json`（默认）、`ndjson`、`table`、`csv` |
+| `--dry-run` | 否 | 预览 API 调用，不执行 |
+
+## 这个命令解决什么问题
+
+当用户只有自然语言意图，还没有 `approval_code` 时，先用它把“可发起的审批定义候选项”找出来。
+
+典型场景：
+
+- “帮我找一下请假审批”
+- “有哪些可以发起的报销单？”
+- “先搜一下出差审批，再帮我提单”
+
+## 输出重点字段
+
+返回结果里，优先关注以下字段：
+
+| 字段 | 说明 |
+|------|------|
+| `approval_code` | 审批定义 Code；后续 `approvals get` 和 `instances create` 都要用它 |
+| `approval_name` | 审批定义名称；给用户做候选选择时最关键 |
+| `is_external` | 是否为三方审批定义；`true` 表示不能走原生 `instances.create` |
+| `create_link` | 三方审批定义的发起链接；`is_external=true` 时优先返回给用户 |
+
+## 使用规则
+
+- **这是发起审批工作流的第一步。** 标准顺序是：`approvals search` -> `approvals get` -> `instances create`。
+- **搜索结果为空时，不要猜。** 直接告诉用户当前关键词下没有可发起定义，并建议用户换关键词。
+- **命中多个结果时，不要替用户拍板。** 先把候选定义列出来，让用户选择目标审批定义。
+- **`is_external=true` 时不要调用 `approval instances create`。** 这类定义属于三方审批，优先返回 `create_link` 并说明需要通过链接发起。
+- **只有 `is_external=false` 的原生定义，才继续 `approvals get`。**
+- **如果用户已经明确给出 `approval_code`，不要再 search。** 直接执行 `approval approvals get`。
+
+## 结果整理方式
+
+**将结果整理为候选清单，优先展示“名称 + approval_code + 是否三方定义 + 下一步建议”。**
+
+建议输出成下面这种结构：
+
+```text
+找到 3 个可发起审批定义：
+
+1. 请假申请
+   - approval_code: 7C468A54-8745-2245-9675-08B7C63E7A85
+   - is_external: false
+   - next: 可继续读取 definitions 详情（approvals get）
+
+2. 差旅报销
+   - approval_code: 99887766-xxxx
+   - is_external: true
+   - next: 返回 create_link，引导用户通过链接发起
+```
+
+## 常见后续操作
+
+### 1）用户选中了某个定义，继续查看详情
+
+```bash
+lark-cli approval approvals get --params '{"approval_code":"<APPROVAL_CODE>"}' --as user
+```
+
+### 2）确认是原生定义后，再准备发起审批实例
+
+```bash
+lark-cli approval instances create --data '{"approval_code":"<APPROVAL_CODE>","form":"[...]"}' --as user --yes
+```
+
+### 3）确认是三方定义时，直接返回链接
+
+当 `is_external=true` 时，优先向用户返回 `create_link`，说明该审批需在三方系统或跳转页面中发起，而不是通过原生 `instances.create`。

package/skills/lark-approval/references/lark-approval-initiate.md

@@ -0,0 +1,221 @@
+# 审批提单工作流
+
+## 执行摘要
+
+- **原生审批提单如果用户未明确给出 `approval_code`，必须固定走 `approvals search` -> `approvals get` -> `instances create`** 不要跳过 `get` 直接拼请求。
+- **原生审批提单如果用户明确给出 `approval_code`，固定走 `approvals get` -> `instances create`** 不要跳过 `get` 直接拼请求。
+- **`is_external=true` 的定义是三方定义。** 这类定义不要调用 `instances create`，应优先使用 `create_link`。
+- **所有人员类参数默认使用 `open_id`。** 若用户给的是姓名、邮箱或其他身份，先用 [`../../lark-contact/SKILL.md`](../../lark-contact/SKILL.md) 解析。
+- **先读控件参数 reference 和值来源 reference，再读本文里的创建参数规则。** 提单前必须先阅读 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 和 [`lark-approval-instance-value-sourcing.md`](./lark-approval-instance-value-sourcing.md)。
+- **`approvals.get.form` 不是创建 payload 的原样模板。** 它主要用于识别控件 `id`、`type`、选项值范围和明细子控件结构；真正的 `instances create --data.form` 中，控件 `value` 结构以 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 为准。
+- **节点参数只从 `node_list` 和本文里的节点参数规则里取。** 节点 key 必须来自定义详情返回的节点标识；审批人/抄送人列表传用户 ID 时，不要混用姓名或其他身份标识。
+- **看到 `need_approver=true` 就说明该节点需要发起人补充审批人。** 如果 `approver_chosen_multi=false`，该节点只允许一个 `open_id`。
+- **创建实例前先确认。** `approval instances create` 是写操作，执行前，让用户确认最终定义、表单值和节点参数；真正执行时显式传 `--yes`。
+
+## 适用场景
+
+- “帮我提交一个请假审批”
+- “帮我发起报销审批”
+- “我想提一个出差审批”
+- “先搜可发起的审批，再帮我提单”
+
+## 严禁行为
+
+- **严禁在未先阅读本文中的创建参数规则、[`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 和 [`lark-approval-instance-value-sourcing.md`](./lark-approval-instance-value-sourcing.md) 的情况下直接提单。**
+- **严禁跳过 `approvals.get`。** 未拿到 `form` 和 `node_list` 前，不得调用 `instances create`。
+- **严禁把姓名直接写进 `node_approver_list`、`node_cc_list` 或表单人员控件。** 必须先转成 `open_id`。
+- **严禁对三方定义调用 `instances create`。**
+- **严禁对 API 不支持的控件硬提单。** 如果目标定义包含创建实例 API 不支持的控件，应明确告诉用户该定义不能仅通过 API 完整发起。
+- **严禁把 `approvals.get.form` 当成可直接提交的原样模板。**
+- **严禁在未得到用户确认前直接执行真实提单。**
+
+## 工作流
+
+### 1. 搜索可发起审批定义
+
+先搜索定义：
+
+```bash
+lark-cli approval approvals search --data '{"keyword":"请假"}'
+```
+
+处理规则：
+
+- 若结果为空，告诉用户当前关键词下没有可发起定义。
+- 若命中多个定义，必须把候选项列给用户选择，不要自行猜测。
+- 若目标定义 `is_external=true`，优先返回 `create_link`，说明这是三方定义，不能走原生 `instances create`。
+- 只有 `is_external=false` 的原生定义才继续下一步。
+
+### 2. 获取审批定义详情
+
+拿到 `approval_code` 后，读取定义详情：
+
+```bash
+lark-cli approval approvals get \
+  --params '{"approval_code":"7C468A54-8745-2245-9675-08B7C63E7A85"}'
+```
+
+重点关注返回：
+
+- `approval_name`: 当前发起的是哪个审批定义。
+- `form`: 表单定义快照，用于识别控件 `id`、`type`、选项值范围以及明细子控件结构；不是创建实例时可直接原样提交的 payload 模板。
+- `node_list`: 流程节点信息，是后续 `node_approver_list` / `node_cc_list` 的唯一可靠来源。
+
+### 3. 创建请求参数速查
+
+输入参数如下：
+
+| 参数 | 必填 | 说明 |
+|---|---|---|
+| `--data '{...}'` | 是 | 请求体，使用 JSON 传入 |
+| `approval_code` | 是 | 审批定义 Code；必须先通过 `approvals search` / `approvals get` 确认 |
+| `form` | 否 | 表单值，**JSON 数组字符串**，不是普通对象；API 层非必填，但审批定义存在必填控件或用户需要提交表单值时必须传 |
+| `node_approver_list` | 否 | 节点审批人列表；仅在定义要求补充审批人时传 |
+| `node_cc_list` | 否 | 节点抄送人列表；仅在用户明确需要补充节点抄送人时传 |
+| `uuid` | 否 | 幂等标识；重复重试同一请求时建议显式传入 |
+| `--as user` | 否 | 建议显式指定用户身份；审批发起通常应使用用户身份 |
+| `--yes` | 是 | 写操作确认；真实执行时必须显式传入 |
+| `--dry-run` | 否 | 预览 API 调用，不执行 |
+
+### 4. 组装 `form`
+
+`instances create --data.form` 是可选字段；传入时必须是一个 JSON 数组字符串。无表单或无需填写表单值的审批可省略 `form`，但只要审批定义包含需要提交的控件，就必须按控件结构组装后传入。组装原则：
+
+- 先用 `approvals.get.form` 识别有哪些控件、每个控件的 `id` / `type` / 可选值范围，再按本文中的创建参数规则与 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 重新组装创建 payload。
+- 提交时必须至少保证每个控件的 `id`、`type` 与 `value` 符合当前接口要求；不要假设定义快照里出现的其他字段都能直接照搬。
+- 如果用户提供的是人员信息，优先转换成 `open_id` 后再写入对应控件。
+- 单选/多选控件提交的是选项 `value`，该值可从 `approvals.get.form` 的选项定义中取得。
+- `contact`、`department`、`fieldList`、`dateInterval`、`amount`、`telephone`、`document` 等控件的 `value` 结构各不相同，必须按 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 单独组装，不要套用文本控件的写法。
+- 值本身从哪里拿，优先按 [`lark-approval-instance-value-sourcing.md`](./lark-approval-instance-value-sourcing.md) 处理；不要把“知道结构”误当成“已经拿到可提交值”。
+- 若 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 标明某控件不支持通过创建实例 API 提交，则不要硬猜绕过；应明确告诉用户该定义当前无法仅通过 API 提单。
+- 若遇到当前 skill 未明确覆盖的复杂控件，不要硬猜；先依据 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 判断支持性与传值结构，再向用户确认。
+
+## API 不支持的控件
+
+根据 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md)，创建审批实例 API 不支持的控件至少包括：
+
+- `text`
+- `mutableGroup`
+- `account`
+- `serialNumber`
+- `tripGroup`
+- `apaascorehrOnboardingGroup`
+- `apaascorehrRegularateGroup`
+- `remedyGroupV2`
+- `apaascorehrJobAdjustGroup`
+- `apaascorehrOffboardingGroup`
+
+如果目标审批定义包含上述控件，不要继续硬拼 `form`；应直接告诉用户该定义不能仅通过当前 API 完整提单。
+
+## 高频控件速查
+
+优先按 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 组装，下面只保留最常用、最容易出错的格式：
+
+- `input` / `textarea`: `value` 是字符串
+- `date`: `value` 是 RFC3339 时间字符串
+- `dateInterval`: `value` 是对象，包含 `start` / `end` / `interval`
+- `radio` / `radioV2`: `value` 是单个选项值，取定义详情里的 `option.value`；关联外部选项时传 `options.id`
+- `checkbox` / `checkboxV2`: `value` 是选项值数组
+- `number`: `value` 是数字
+- `amount`: `value` 是数字，还要带 `currency`
+- `formula`: `value` 必须与定义中的公式结果匹配，否则会报错
+- `contact`: 只推荐写 `open_ids`，由人员信息先转换成 `open_id`
+- `connect`: `value` 是关联审批实例 `instance_code` 数组，当前默认要求用户直接提供 `instance_code`
+- `document`: `value` 是对象，至少含 `token` 和 `type=docx`
+- `attachmentV2` / `image` / `imageV2`: `value` 是 file code 数组，当前默认要求用户直接提供
+- `fieldList`: `value` 是二维数组，子项继续按各自控件类型组装
+- `department`: `value` 是对象数组，元素字段名为 `open_id`，其值填写部门的 `open_department_id`
+- `telephone`: `value` 是对象，包含 `countryCode` 和 `nationalNumber`
+- `address`: `value` 是对象数组，至少包含地理库 `id`，可选 `detailAddress`；当前默认要求用户直接提供该 `id`
+
+## 特殊控件组
+
+[`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 还明确给出了若干特殊控件组的提单格式，至少包括：
+
+- `leaveGroupV2`
+- `workGroup`
+- `outGroup`
+- `shiftGroup`
+
+这类控件组不是简单文本控件，通常内部还嵌套 `radioV2`、`date`、`fieldList`、`image`、`contact` 等子控件。遇到这些控件组时：
+
+- 先从 `approvals.get.form` 找到控件组及其子控件 ID
+- 再严格按 [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md) 的示例组装 `value`
+- 不要把控件组整体当成普通字符串或扁平对象提交
+
+### 5. 组装节点参数
+
+从 `node_list` 推导节点参数：
+
+- 若某节点 `need_approver=true`，则必须在 `node_approver_list` 中补该节点的审批人。
+- `key` 优先取 `custom_node_id`；若不存在，再用 `node_id`。
+- `value` 是审批人 `open_id` 列表。
+- 若 `approver_chosen_multi=false`，该节点只允许一个审批人 `open_id`。
+- `node_cc_list` 仅在用户明确需要补充节点抄送人时才填写；其 `key/value` 规则与 `node_approver_list` 相同。
+
+### 6. 创建审批实例
+
+创建命令使用 `approval instances create`，需要的 scopes: ["approval:instance:write"]
+
+确认最终表单值和节点参数后再执行：
+
+```bash
+lark-cli approval instances create \
+  --data '{
+    "approval_code":"7C468A54-8745-2245-9675-08B7C63E7A85",
+    "form":"[{\"id\":\"widget1\",\"type\":\"input\",\"value\":\"请假半天\"}]",
+    "node_approver_list":[
+      {
+        "key":"manager_node_id",
+        "value":["ou_xxx"]
+      }
+    ]
+  }' \
+  --as user \
+  --yes
+```
+
+执行规则：
+
+- 执行前先向用户确认：目标审批定义、核心表单值、节点审批人/抄送人。
+- 若需要幂等，可补 `uuid`。
+- 成功后回报 `instance_code` 与 `instance_link`。
+
+## 组装时优先依据的资料
+
+优先级固定如下：
+
+1. 本文中的创建请求参数、节点参数和返回结果说明：决定 `instances create` 要传哪些字段、怎么执行、成功后回什么。
+2. [`lark-approval-instance-form-control-parameters.md`](./lark-approval-instance-form-control-parameters.md)：决定每种控件的 `value` 结构与支持范围。
+3. [`lark-approval-instance-value-sourcing.md`](./lark-approval-instance-value-sourcing.md)：决定每类值应该从哪里拿，以及当前哪些值必须由用户直接提供。
+4. `approvals.get.form`：提供当前审批定义里实际有哪些控件、控件 `id`、控件 `type`、选项值范围、明细子控件结构。
+5. `approvals.get.node_list`：提供节点 key 与是否需要补充审批人/抄送人的线索。
+
+不要反过来把 `approvals.get.form` 当成第一优先级，更不要把它当成可直接提交的 JSON 模板。
+
+## 最小判断表
+
+| 你手上有什么 | 下一步 |
+|---|---|
+| 只有口语需求，比如“帮我提个请假审批” | 先 `approvals.search` |
+| 已经拿到 `approval_code` | 直接 `approvals.get` |
+| 已拿到 `form` / `node_list`，且用户已给出表单值和审批人 | 组装 `instances create` |
+| `is_external=true` | 返回 `create_link`，不要调 `instances create` |
+
+## 返回结果
+
+完成创建后，至少向用户返回：
+
+- `approval_name`
+- `instance_code`
+- `instance_link`
+
+建议整理为下面这种结构：
+
+```text
+审批已创建成功：
+
+- approval_name: 请假申请
+- instance_code: 19EAC829-F1CB-527F-BE2A-1330422E60C0
+- instance_link: https://...
+```