WeCom To-Do List Query Skill
is a command line program provided by WeCom, and all operations are completed by executing
commands.
Query WeCom to-do list via
, supporting time filtering and pagination.
Behavior Strategy
Must query details after getting the list: This interface only returns summary information such as to-do ID and status, and does not include the actual content of the to-do and the assignee. For users, a to-do list without content is completely useless - what they want to know is "what to do", not a string of IDs. Therefore, after each call to get_todo_list to get the result, you must immediately use the returned todo_id list to call
to get complete details (content, assignee, etc.) before displaying them to the user. This is not an optional step, but a necessary link to complete the user's request.
Must remind users when pagination is not fully pulled: The interface is paginated, and it is not required to pull all data at one time. But if
in the response is
, it means that there are still to-dos not returned later - when you display the current results, you must clearly tell the user "There are more to-dos not displayed, do you need to continue viewing?". Users may not know that there is more data later, if you don't mention it, they will think what they see is all, which will lead to missing important to-dos. This is a point that is easy to ignore but has serious consequences, please be sure to implement it.
Retry strategy: When encountering "return HTTP error" or "HTTP request failure", take the initiative to retry, up to three times.
Calling Method
bash
wecom-cli todo get_todo_list '<json格式的入参>'
Parameter Description
| Parameter | Type | Required | Description |
|---|
| string | ❌ | Creation start time, format: |
| string | ❌ | Creation end time, format: |
| string | ❌ | Reminder start time, format: |
| string | ❌ | Reminder end time, format: |
| number | ❌ | Maximum number of returned items, default 10, maximum 20 |
| string | ❌ | Pagination cursor, not passed for the first request, pass the of the last response for subsequent requests |
Return Format
json
{
"errcode": 0,
"errmsg": "ok",
"index_list": [
{
"todo_id": "TODO_ID",
"todo_status": 1,
"user_status": 1,
"creator_id": "CREATOR_ID",
"remind_time": "2025-06-01 09:00:00",
"create_time": "2025-01-15 10:30:00",
"update_time": "2025-01-16 14:20:00"
}
],
"next_cursor": "NEXT_CURSOR",
"has_more": false
}
Return Field Description
| Field | Type | Description |
|---|
| array | To-do list |
| string | Unique to-do ID |
| number | To-do status: -Completed, -In progress, -Deleted |
| number | User status: -Rejected, -Accepted, -Completed |
| string | Creator ID |
| string | Reminder time |
| string | Creation time |
| string | Update time |
| string | Next page cursor |
| boolean | Whether there are more records |
The list returns to-do summary information (excluding content and assignees). After getting the list, you must call
to get complete details before displaying them to the user.
Typical Workflow
View To-do List (Standard Two-step Process)
User asks: "Check my recent to-dos" / "What to-do items do I have?" / "How many things do I still have to do?"
- Step 1: Get the to-do list (only ID and status, no content).
bash
wecom-cli todo get_todo_list '{}'
- Step 2 (Prohibited to skip!): Call wecomcli-get-todo-detail with the returned todo_id list to get complete details.
bash
wecom-cli todo get_todo_detail '{"todo_id_list": ["返回的TODO_ID_1", "返回的TODO_ID_2"]}'
Both steps are indispensable - only after getting the details can you display meaningful to-do content to the user.
- Step 3 (Conditional execution): Check the field returned in the first step. If it is , you must remind the user when displaying the results: "The above are part of the to-dos, there are more to-dos not displayed, do you need me to continue checking?" - If you don't remind, users will think this is all.
Query by Time Range
User asks: "What are the to-dos created this month?"
bash
wecom-cli todo get_todo_list '{"create_begin_time": "2025-03-01 00:00:00", "create_end_time": "2025-03-31 23:59:59"}'
Pagination to Get a Large Number of To-dos
When the number of to-dos exceeds the single-page limit, pull pages cyclically through
:
- First request (no cursor passed):
bash
wecom-cli todo get_todo_list '{"limit": 20}'
If the pulling is not completed and there are more to-dos, it will return has_more=true, next_cursor="CURSOR_1"
- Second request (pass the next_cursor from the last time):
bash
wecom-cli todo get_todo_list '{"limit": 20, "cursor": "CURSOR_1"}'
Return has_more=false, pulling completed
Pagination rules:
- Do not pass for the first request
- When is , pass as the of the next request
- Stop the request when is
- The time filter parameters remain unchanged during pagination
- If you choose not to continue turning pages (for example, the current page data is enough), you must tell the user that there are more to-dos not displayed, and ask the user if they need to continue viewing
Notes
-
Time format: All time parameters use the
format. When users say relative times such as "tomorrow", "next Monday", calculate the specific date according to the current date
-
Status value meaning
- To-do status (): -Completed, -In progress, -Deleted
- User status (): -Rejected, -Accepted, -Completed
-
Error handling: If
is not
, inform the user of the error information in
-
Must query details: This interface returns summary information (excluding content and assignees). After getting the list, you must immediately call
to get the complete content before displaying it to the user, do not only display the list summary
-
Must remind when pagination is not fully pulled: If the returned
is
, when displaying the results to the user, you must clearly state "There are more to-dos not displayed" and ask the user if they need to continue viewing. Users do not know that there is more data later, and not reminding will lead to omissions