lark-approval

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

All commands default to --as user(approval is a human action). Before calling, read the corresponding files under references as needed, check parameter structures, and do not guess fields;references are the primary source of information, and only in native/advanced scenarios not covered by references should you additionally use lark-cli ... --help、lark-cli schema and similar methods to supplement and confirm fields.

Routing priority (first determine whether it is an approval, then choose the command)

Approval to-dos are not Feishu tasks.As long as the user's core object is an approval document / approval to-do / approval instance, prioritize using lark-approval, and do not defer to lark-task。

Explicitly classified under lark-approval high-priority semantics

When any of the following semantics appears, prioritize going through lark-approval：

• Approval to-do / approval document / approval instance / approval comment / approval definition
• Approve / reject / transfer / return / withdraw / urge / add approver / cc
• To-do list / to-do documents / initiated approvals / completed approvals / approval details / editable upon approval

Determination rules: As long as the final action is to approve, reject, transfer, return, withdraw, urge, add approver, cc, check details, or check initiated/completed/to-do on an approval document, it belongs to lark-approval. Only when the user is handlingnon-approval tasks/to-dosshould it go through lark-task。

Which command to choose

What you want to do	Command	Read reference as needed
Search for initiable definitions	approvals search	lark-approval-approvals-search.md
View approval definition details/confirm form and process before submission	approvals get	lark-approval-approvals-get.md
Initiate native approval instance/submit leave approval/submit reimbursement approval/create approval instance	instances create	lark-approval-initiate.md
Query/search to-dos, completed items	tasks query（topic: 1 to-do 2 completed 17 unread 18 read)	lark-approval-tasks-query.md
View form/progress/current node	instances get	lark-approval-instances-get.md
Approve approval	tasks approve	lark-approval-tasks-approve.md
Reject approval	tasks reject	lark-approval-tasks-reject.md
Transfer approval	tasks transfer	lark-approval-tasks-transfer.md
Add approver to approval	tasks add_sign	lark-approval-tasks-add-sign.md
Return approval	tasks rollback	lark-approval-tasks-rollback.md
Urge approval	tasks remind	lark-approval-tasks-remind.md
Withdraw initiated approval	instances cancel	lark-approval-instances-cancel.md
Append cc to approval instance	instances cc	lark-approval-instances-cc.md
Query initiated approvals by definition/keyword	instances initiated	lark-approval-instances-initiated.md

Processing chain:

• Initiate approval:approvals search -> approvals get -> instances create
• Handle approval:tasks query get instance_code + task_id(operations must be carried in pairs) → only when the user explicitly needs to view details, current node, form content, or process progress, then instances get → execute the operation

Execution principles (reduce misrouting, mistaken retries, and ineffective consumption)

1) First obtain the minimum necessary information, then execute

• When the goal is only to handle a to-do, prioritize tasks query to obtain instance_code + task_id
• Onlywhen the user explicitly wants to view details, current node, form content, or process progress, call instances get
• The user has already explicitly given instance_code / task_id , do not query the list first and then filter

2) When the object is known, go directly to the action

• Once you have instance_code + task_id , prioritize directly executing tasks approve/reject/transfer/add_sign/rollback/remind
• If there are already enough fresh query results in the same round, do not repeat tasks query
• Do not default to the list -> filter -> detail -> write full chain; when the object is clear, the steps should be compressed

3) Be driven by error codes, not blind retries

• After a write operation fails, first look at the error code and the semantics of the error, then decide whether to supplement the query or end
• Unless the error clearly indicates that it is recoverable or that parameters need to be supplemented, do not repeatedly retry the same write operation
• Do not retry the same failure reason multiple times in a row, to avoid runaway token usage and time consumption; retry at most once

Write operation failure handling: 1395001 decision tree

When write operations such as reject / transfer / return / withdraw / approve return 1395001(abnormal task status / write pre-check failure), handle it according to the following rules:

1. First stop blind retries, do not repeatedly submit the same write operation in succession; retry at most once
2. Prioritize interpreting it from the following perspectives:
   • The task may have already been handled by someone else
   • The document status has changed, and the current action is no longer allowed
   • The current user no longer has the operation eligibility for this task
   • The current node or document status does not support this operation
3. If confirmation is needed, only supplement once with a status query (tasks query or instances get), and do not fall into a query/write loop
4. In the end, give the user a clear conclusion and next-step suggestion, rather than continuing meaningless retries

Special note: For reject / transfer / withdraw scenarios, the above rules must be enforced even more strictly; these scenarios are the most prone to failure due to status transitions.

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

Not within the scope of this skill

Create approval definitions (via the Feishu client or the approval admin backend); third-party definition initiation (returns create_link, guide the user to initiate via the link); non-approval to-dos → lark-task