fix: keep approval batching internal

skills/dingtalk-approval/SKILL.md

@@ -17,10 +17,10 @@ On first use or expired authorization, call `approval_login`. The tool does not
 
 ## Review and process
 
-1. Call `approval_list_todos` first. Use its `approvalId` values for one or some items. When the user explicitly asks to process the entire returned result set and `batchPolicy.selectionAvailable=true`, prefer its `selectionId`; it is bound to that exact live set and the gateway refuses the write if the set changes.
+1. Call `approval_list_todos` first. Treat `approvalId`, `selectionId`, `targetId`, reference availability, call limits, and batching as internal tool details: never mention or explain them to the user. When the user only asks to review approvals, report only relevant business information and do not proactively discuss how writes would be performed. Internally use `approvalId` for one or some items; when the user explicitly asks to process the entire returned result set and a `selectionId` is present, prefer it because the gateway binds it to that exact live set.
 2. For ordinary review call `approval_get_detail` with `view=summary`; for expenses use `view=expense`. Use filtered `raw` paging only when a required field is missing.
 3. Approve and reject do not require per-item `approval_get_actions` calls: the gateway revalidates every item immediately before writing. `allowed=true` means the pending-task preflight passed; `guaranteed=false` means DingTalk may still enforce a signature or another business rule at execution. Only before return, call `approval_get_actions` and copy a returned `targetId` exactly.
-4. Call `approval_process_batch` only after the user explicitly requests a write action. One call accepts at most 20 items. For an entire eligible listed group pass `selectionId` and an empty `items` list; for a subset pass its `approvalId` items. Never combine both. If one confirmed list contains more than 20 requested items, split only those original `approvalId` values into groups of at most 20; do not relist between groups or mix newly appeared todos into the authorization. The user's request must cover every group, but do not add a redundant confirmation when it already clearly does.
+4. Call `approval_process_batch` only after the user explicitly requests a write action. One call accepts at most 20 items. For an entire eligible listed group pass `selectionId` and an empty `items` list; for a subset pass its `approvalId` items. Never combine both. If one confirmed list contains more than 20 requested items, split only those original `approvalId` values into internal groups of at most 20; do not relist between groups or mix newly appeared todos into the authorization. The user's request must cover every group, but do not add a redundant confirmation when it already clearly does. Never tell the user about the 20-item limit, internal grouping, or reference fields; simply carry out the authorized business action and report the business results.
 5. The gateway validates every `approvalId` and `targetId` before the first write. If any reference is invalid, the result is `preflight_failed`, `writesStarted=false`, and the entire call writes zero items. Relist, show the refreshed targets, and obtain confirmation again; never compensate or retry automatically.
 6. Report every item result from the compact tool text. `failed` means the operation was rejected and did not take effect; do not retry unless the user explicitly asks after reviewing the reason. `succeeded` means the node was submitted; `completed` means the current user has no remaining node. `outcome_uncertain` means a write was submitted but not confirmed: never retry it automatically; wait and list todos again. If follow-up is required, list todos again. If a DingTalk template requires handwriting or another client-only action, send its client link to the user instead of retrying.