处理飞书审批单据/待办/实例时：用 lark-cli 查询…

当用户核心对象是飞书审批待办、审批实例或审批定义，需要查询、处理或发起原生审批时使用。

适用场景

解决思路

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

适用边界 · 注意事项

• 创建审批定义（走飞书客户端或审批管理后台）时不适用。
• 三方定义发起（返回 create_link，引导用户通过链接发起）时不适用。
• 非审批类待办（走 lark-task）时不适用。