wecomcli-meeting

wecom-cli is a tool provided by the plugin, not a terminal command: all operations are performed by calling this tool, and parameters should be passed using args It is prohibited to use it via command-line methods such as exec / shell / terminal.

⚠️ Prerequisite: Before calling wecom-cli for the first time, you must perform the prerequisite check according to the wecomcli-preflight skill to ensure the tool has been added to the whitelist.

WeCom Meeting Skill

This Skill handles the full lifecycle management of WeCom meetings, including creating, querying, searching, and canceling meetings, as well as managing meeting status and participants.

CRITICAL — Operation Execution Protocol(must be followed for every operation):

1. Identify the operation type corresponding to the user's intent (create/query/search/cancel)
2. Use the Read tool to read the reference document for that operation(see the "Operation Reference" table below)
3. Strictly follow the workflow and command format in the reference document
4. Do not skip step 2 and execute the command directly, even if you think you already know how to operate — Reason: the parameter format, optional fields, and boundary behavior of each operation are precisely defined in the reference document, and operating from memory can easily lead to call failures due to parameter errors

Scope

Applicable

• Create / start a new online meeting (including meeting number / join link, allowing remote / video participation; including meetings that are "held offline + remote access by colleagues in other locations")
• View / browse the meeting list (what meetings are coming up recently, check meetings in a certain time period)
• Search meetings (find a meeting by keyword or meeting name)
• View meeting details (subject, time, participants, etc.)
• Update / modify a meeting (change the time, add or remove people; updating recurring meetings is not supported)
• Cancel a meeting (canceling recurring meetings is not supported)

Not applicable

• Create, update, or cancel recurring / repeating meetings (weekly / monthly / daily recurrence) → none are supported; guide the user to operate manually in the WeCom client
• Reply to / decline a meeting invitation (accept / decline / tentative, including "decline this meeting" and "not attending") → not supported; guide the user to operate in the WeCom client or privately message the organizer

Easily Confused Scenario Routing

• What the user wants isA schedule without an online meeting link / a purely offline face-to-face meetup(scheduling an appointment, checking today's arrangements, arranging a purely offline meeting) → use instead wecomcli-calendar
• Check availability / find common free time for multiple people → use instead wecomcli-calendar
• Book / query a company meeting room (book a meeting room, check whether a meeting room is available, check an office building) → meeting room query capabilities are in the wecomcli-calendar skill; when creating/updating a meeting, if you want to book/change a meeting room,读取 wecomcli-calendar 技能 Get the meeting room query reference from meeting_room_id pass into this skill's create/update
• The user only says "have a meeting / schedule a meeting / arrange a meeting / xx meeting", etc.,it is not clear whether it is a schedule or an online meeting(Create scenario) → Must first use text to ask a disambiguation question (fixed question "Do you need to create a schedule or a meeting?", ask the user to reply "schedule / meeting"), and must not assume and create directly
• Only a location / meeting room number was given(e.g., "meet in 1605" "book a meeting room for a meeting") → does not constitute "clearly a meeting"; still need to ask for disambiguation in text first, and cannot skip the follow-up just because a location is included
• Vague expressions in query scenarios("what meetings are coming up / what meetings are there") → strictly forbidden to ask follow-up questions; query both schedules and meetings and merge the display; only when "online meeting / video meeting / join link / meeting number / remote attendance" is explicitly mentioned should only meetings be queried

Routing rules

User intent	Reference document
Create a meeting, hold a meeting, arrange a video meeting	meeting-create
Check meetings, my meeting list, what meetings are coming up, check meetings in a certain time period	meeting-list
Search meetings, find a certain meeting, find last week's weekly meeting	meeting-search
View meeting details, see attendees	meeting-list
Modify a meeting, update a meeting, change the time, add/remove people	meeting-update
Cancel a meeting, no longer holding it	meeting-cancel
View the original meeting transcript, verbatim record, send me the exact words said in the meeting, want the transcript/transcription text, which paragraph of the transcript	meeting-original-get
Summarize the meeting / want meeting minutes / what was this meeting about / view meeting to-dos / summarize to-dos	See the core scenario below "7. Meeting summary (minutes/to-dos)", orchestrate meeting-list 's get and meeting-original-get
Schedule an event, schedule arrangements, see what is on the schedule today	wecomcli-calendar skill
Check busy/free, see when someone is available	wecomcli-calendar skill
Arrange a purely offline face-to-face meeting (without an online meeting link)	wecomcli-calendar skill

Skill boundary (meeting vs schedule) [CRITICAL]: This skill only createsmeetings that include an online meeting link(including meeting number/join link, for remote/video attendance). As long as an online meeting link is involved, it belongs to this skill; a purely offline face-to-face meeting without an online meeting link belongs to schedules, use 读取 wecomcli-calendar 技能. When the user only says "meeting/meet/hold a meeting/set up a meeting/arrange a meeting/xx meeting/xx conference" etc. and does not clarify whether it is a schedule or a meeting,you must first ask in text, and it is forbidden to directly create a meeting by default:

Questions and options are fixed [CRITICAL]: During disambiguation confirmation, both the question and the selectable options must be used verbatim, and modifying any content is strictly prohibited — the question is fixed as "需要创建日程还是会议？", and the selectable options are fixed as 日程 / 会议; do not rewrite the question wording, add or remove or rewrite options, translate, or design other expressions yourself (such as "online meeting / virtual meeting / video meeting / offline meeting", etc.).

Ask the user in text:需要创建日程还是会议？（请回复：日程 / 会议）

If the user answers "meeting" → stay in this skill to create a meeting; if they answer "schedule" → switch to 读取 wecomcli-calendar 技能 to create a schedule.

This text disambiguation is only for "creation"; in query scenarios follow-up questions are strictly prohibited — when it clearly points to an online meeting, query only meetings; when it is clearly a schedule/arrangement, query only schedules; for vague expressions ("meeting / xx meeting / what meetings are coming up", etc.), query both schedules and meetings (see "Query disambiguation" below).

"Meeting", "gathering", "have a meeting" and similar words by themselves do not constitute "explicit" [CRITICAL]: these words only indicate that people need to get together to discuss something, and do not specify whether it is a schedule or a meeting. It is forbidden to default to creating under this skill (meeting) merely because the word "meeting" appears in the query, and it is also forbidden to default to a schedule in the opposite direction—as long as it is not explicit, always first ask a follow-up question in text before routing. Only when explicit signals such as "join link / meeting number / video conference / remote attendance" appear should it be directly routed to meetings.

When both offline and remote attendance are supported(e.g., "held offline, with out-of-town colleagues joining remotely"), because it contains an online meeting link, route to this skill for creation—creating a meeting will simultaneously generate the corresponding schedule, so there is no need to go to the wecomcli-calendar skill to create a separate schedule.

Only a location/meeting room number(e.g., "have a meeting in 1605", "meet up at the meeting room in Building A", "book a meeting room for a meeting") does not constitute "explicitly a meeting"—a meeting room may likewise be just a purely offline arrangement, and whether it is a schedule or a meeting is still unknown, so you must first ask in text for disambiguation, and cannot skip the follow-up just because a location is included.

The principle for choosing list vs search: when the user explicitly mentions a topic/name keyword, use search(pass the keyword into keywords); when only browsing by time range or generally, use list, and it is forbidden to feed the date as keywords to search. The two can sometimes be combined: first use search to locate, then use list to confirm the full picture of the time period.

Query disambiguation (for fuzzy queries, query both schedules + meetings) [REQUIRED]: in query scenarios, it is strictly forbidden to use a text follow-up to ask "is it a schedule or a meeting"—the schedule/meeting disambiguation follow-up is only used for creation; during queries, always handle it directly according to the following rules, without asking follow-up questions.The determination is split into two independent dimensions; do not conflate them：

Dimension one: which side to query (schedule / meeting / both)

• Explicitly an online meeting → when the user explicitly mentions online-meeting-specific features such as "online meeting / video conference / join link / meeting number / Tencent Meeting / remote attendance", stay in this skill and query only meetings.
• Explicitly a schedule/arrangement → when what the user says is clearly schedule-type content (e.g., "schedule / arrangement / my arrangements / calendar", and without online meeting features), switch to 读取 wecomcli-calendar 技能 to query only schedules.
• Ambiguous wording that cannot be determined("meeting / xx gathering / xx meeting / have a meeting / what meetings are coming up / what meetings are there / find xx meeting", etc., which could be either a schedule or a meeting) → query both schedules and meetings: both use this skill to query meetings and 读取 wecomcli-calendar 技能 query schedules.

Dimension two: for each side, use search or list(independent of dimension one; judge each side separately)

• Has a topic/name keyword(e.g., "find xx meeting", "search for the project review meeting") → that side uses search(pass the keyword into keywords）。
• Only time/date or general browsing without keywords(e.g., "what meetings are coming up", "check tomorrow's meetings") → that side uses list, and it is forbidden to feed the date as keywords to search。
• Even if "query both sides", choose separately for each side according to this dimension: when there are keywords, both sides use search; for pure time/general browsing, both sides use list。

Merge display：When querying both sides, merge the results and display them in a unified way — split into "(Meeting)" (those from the meeting side, or those whose schedule contains a meeting.meeting_link that is non-empty) and "(Schedule)" (those whosemeeting_link is empty, i.e., pure schedules). When the same meeting appears on both sides, deduplicate by "subject + time" and keep only one entry; at the end, summarize "Total N meetings, of which X are meetings and Y are schedules".

• This disambiguation applies only to queries; for creation, still ask with text based on "schedule vs meeting" as described below.

Example trigger expressions：

• "Help me set up a meeting" / "Arrange a meeting" / "Create a video conference"
• "Look at my meetings" / "Check tomorrow's meetings" / "What meetings are coming up recently"
• "Search for the project review meeting" / "Find last week's weekly meeting"
• "Cancel that meeting" / "This meeting is no longer happening"
• "Help me summarize the xx meeting" / "What was discussed in this meeting" / "Send me the meeting minutes for xx" / "Check the to-dos from this meeting" / "Organize this meeting by decision points"

Prerequisites

• Requires a WeCom account and being logged in
• Cancel/update operations are not preemptively blocked based on "whether it was created by the user"; execute the command directly and determine whether the operation is allowed based on the result returned by the API
• Attendee userid (with the prefix wo) is assembled as [{"userid": "woxxx"}] and passed in as an object array; when the user provides a name, resolve it to a userid via 读取 wecomcli-contact 技能 parsed as userid

Core scenarios

1. Create a meeting

Create a new meeting with the current user as the organizer.

CRITICAL — Before execution, the reference document must first be read: upon receiving the intent to create a meeting, the first step is to immediately read meeting-create, and execute step by step according to the complete workflow within it (parameter completion → attendee resolution → attendee availability check → call the creation API → retrieve details for display). It is forbidden to directly initiate any operation without having read the reference document.

Attendee availability check [REQUIRED]: When creating/updating a meeting, availability must be checked before the time is finalized, to avoid scheduling a conflicting time. The availability API is not part of this skill; you must 读取 wecomcli-calendar 技能 refer to the read wecomcli-calendar skill Availability query reference call free listfree list。When creating a meeting: query targets = the current user themself + other internal attendees (wo prefix),even if it is only yourself, you must still check(to avoid booking a time slot you already occupy); external contacts (wm, whose availability cannot be checked) are not included in the query targets, butdo not skip the overall check because of this; only downgrade and allow through when the availability API call itself fails.When adding people to an existing meeting without changing the time: the availability query targets only thenew attendees, and checks the meeting's original time slot. It is forbidden to include the current user (yourself/the creator) and existing attendees — they are occupied by this meeting and will necessarily show as "busy", and including them would cause false conflict reports (see the meeting-update workflow for details).

Meeting room booking [REQUIRED]: When the user mentions intentions such as "book a meeting room / hold it in 1605 / find a meeting room / a meeting room in some building" while creating a meeting, the meeting room query capability is not part of this skill — you must 读取 wecomcli-calendar 技能 refer to the read wecomcli-calendar skill Meeting room query reference（buildings list + rooms search) to find a real meeting room, and take the meeting_room_id and pass it to meeting create(occupied). It is forbidden to write the meeting room name only into location, and it is forbidden to fabricate from memory/guesswork meeting_room_id; book the room first and then create the meeting, see meeting-create Step 4.

See meeting-create

2. Query meeting list

CRITICAL — The reference document must be read before execution: after receiving the intent to query the meeting list, the first step is to immediately read meeting-list, and execute according to the complete workflow in it (determine time range → pull list → batch obtain details → look up participant names → merge output). It is forbidden to directly initiate any operation without having read the reference document.

Fuzzy queries must check both calendar and meetings [CRITICAL]: if this is a fuzzy query such as "meeting / xx meeting / xx conference / what meetings are there recently / which meetings are there / find xx meeting" (see "Query Disambiguation" above), then regardless of whether the meeting list returns results, you must also 读取 wecomcli-calendar 技能 use the same time range to pull the calendar list, merge the results from both sides, and display them summarized in two parts, "(Meetings)" and "(Calendar)", according to whether they contain an online meeting link (deduplicate the same meeting by subject + time). It is forbidden to skip the calendar query just because the meeting has already been found. Only when the userclearly refers to an online meeting(join link / meeting number / video conference / remote participation, etc.) should only meetings be queried; in that case, if none are found, then fall back to checking the calendar as well (if a match is found, explain "This is a calendar entry"; if neither side has it, then inform the user).

See meeting-list

3. Search meetings

Match the meeting subject or content by keyword. When there is a keyword, do not perform a specific follow-up operation to complete the time; search directly. Suitable for scenarios where the user knows the meeting name or keyword.

Fuzzy search must search both calendar and meetings [CRITICAL]: if what the user searches is a fuzzy target such as "meeting / xx meeting / xx conference" (not a clearly online meeting), then regardless of whether the meeting is found, you must also 读取 wecomcli-calendar 技能 use the same keyword to search the calendar, merge the results from both sides and display them summarized under "(Meetings)" and "(Calendar)"; only whenclearly refers to an online meetingshould only meetings be searched; in that case, if none are found, then fall back to searching the calendar (if a match is found, explain "This is a calendar entry"; if neither side has it, then inform the user).

See meeting-search

4. Cancel meeting

CRITICAL — The reference document must be read before execution: after receiving the intent to cancel a meeting, the first step is to immediately read meeting-cancel, and execute according to the complete workflow in it (locate meeting → status check → recurrence determination → execute cancellation → judge by returned result). It is forbidden to directly initiate any operation without having read the reference document.

See meeting-cancel

5. Update meeting

CRITICAL — The reference document must be read before execution: after receiving the intent to update/modify a meeting, the first step is to immediately read meeting-update, and execute according to the complete workflow in it (locate meeting → recurrence determination → parameter collection → execute update → judge by returned result). It is forbidden to directly initiate any operation without having read the reference document.

See meeting-update

6. Query meeting transcript text

CRITICAL — The reference document must be read before execution: after receiving the intent to query the meeting transcript text ("original words/verbatim record/complete dialogue/transcript/transcription/which paragraph", etc.), the first step is to immediately read meeting-original-get, execute according to the complete workflow within it (locate meeting → determine paragraph → pull transcript → paginate and concatenate → output as-is), and do not initiate any operation directly without reading the reference document.

Transcript original text ≠ Smart meeting notes [CRITICAL]: the transcript original text (original_data, sentence-by-sentence original speech) and the AI-summarized meeting get in notes(meeting notes/to-dos) are two different types of content; it is prohibited to use meeting notes to replace the transcript original text.media_index is not passed by default—when not passed, the interface returns the transcript of all segments; only when the user explicitly asks for "paragraph N" should you pass N-1(starting from 0), and do not proactively ask which paragraph is wanted.has_more when true, you must paginate to the end and concatenate in order; when outputting,preserve as-isthe line-by-line format of timestamp + speaker, without summarizing or trimming.

See meeting-original-get

7. Meeting summary (meeting notes / to-dos)

The user wants to "summarize a certain meeting"—including asking formeeting notes, asking "what was this meeting about", asking formeeting to-dos, "summarize the to-dos", etc. This is essentially orchestrating the two existing meeting get(ready-made meeting notes/to-dos) and meeting original get(transcript original text) interfacesorchestration, with no new interface.Meeting notes and to-dos follow the same logic, and are handled in the same way.

CRITICAL — the reference document must be read before execution: first use meeting-list to locate the meeting and (when there is no custom requirement) get get; when you need to go back to the original text for processing, read meeting-original-get。

The only branching dimension: whether this summary includes a "custom requirement / description"

As long as the user attaches any custom requirement, description, angle, scope, structure, or style beyond "summarize", always go through original-text generation；Only when the user purely says "summarize / what was it about / send me the notes / look at the to-dos" without any additional description should the existing ready-made content be returned。

• Only saying "summarize" (without any custom description): only generally wants a summary/overview/to-do list, without attaching any requirement. Trigger phrases such as "summarize the xx meeting", "what was this meeting about", "send me the notes", "look at this meeting's to-dos", "what to-dos are there".
  1. First call meeting get, and take the target field: for meeting notes → look at notes[].note_content; for to-dos → look at notes[].todo_content。
  2. if available, directly return the official ready-made content(determination:has_note_permission == true and the target field has substantive content), with no need to call the transcript original text interface again.
  3. Unavailable(target field empty / has_note_permission == false) → switch to the original-text fallback below.
• Any custom requirement / description attached: as long as the user attaches any description such as structure, angle, focus scope, style, or length, it belongs to this category. Trigger phrases such as "organize by decision points", "use a three-part format", "list each person's speaking highlights", "focus on the budget part", "write it as formal meeting notes", "summarize in one sentence", "combine with the previous meeting and talk about progress", etc.
  • Skip get, directly use meeting original get to pull the full transcript, and process and summarize according to the user's requirements/description. Reason: the official notes is a finished product with a fixed view and cannot satisfy any customization needs; you must go back to the original text and reprocess it.

Original-text fallback order [REQUIRED]: whenever the original text is needed (get is unavailable, or custom requirements are involved), always first call meeting original get(page through to the end), then handle according to the result:

• API error (no permission/other) → report truthfully according to the API response, do not fail silently.
• Succeeded but original_data is empty → inform "this meeting currently has no smart summary, and there is no transcribed original text either (meeting transcription may not have been enabled, the meeting may not have started, or there may be no speech records)", do not fabricate.
• Succeeded and has content → summarize according to the default or user-specified structure (at this point original get is allowed to process and summarize, which differs from outputting as-is when "the exact words/verbatim record" is requested).

See meeting-list(locate + get) and meeting-original-get(fetch the original text and process it).

Core concepts

• Meeting: a WeCom meeting entity, containing attributes such as the subject, start and end times, attendees, and the join link.
• Meeting ID (meeting_id): the unique meeting identifier used by the API, a relatively long string (with themt prefix).
• Meeting code (meeting_code): a 9-digit pure number, used only by users to join the meeting, and cannot be used as meeting_id.
• Recurring meeting: a meeting that repeats according to a rule;update/cancel are all unsupported (see "Known limitations"); only original get when querying the transcribed original text of a certain occurrence, sub_meeting_id。
• Attendee: identified by userid (with thewo prefix). When the user provides a name, resolve it to a userid via 读取 wecomcli-contact 技能 .

Core rules

Rule 1: obtaining userid

• attendees The field format is a [{"userid": "woxxx"}, {"userid": "woyyy"}] array of objects; it does not accept names, and does not accept a flat string array.
• When the user provides a name, resolve it to the corresponding userid via 读取 wecomcli-contact 技能 ; when there are multiple candidates, use text to let the user choose, do not guess on your own.
• Prohibitedto concatenate a name as a userid;Prohibitedto fabricate a userid from memory or guesswork.
• open_vid and userid are different names for the same concept; the open_vid returned by other systems can be used directly as userid .

Rule 2: write operations are executed directly

• When creating or canceling a meeting, execute directly once the parameters are ready, without showing the user a summary or asking for confirmation.
• When returning results,exposing userid is prohibited, and only names are shown.
• Reason: the upper-layer interaction has already fully displayed the operation content and completed confirmation; showing it again here would be redundant; userid is an internal system identifier and has no practical meaning to the user, and displaying it is instead likely to cause confusion.

Rule 3: parameter completion

In any operation, when required parameters are unclear or the user needs to make a choice,you must ask the user directly in text, and you are prohibited from guessing on your own or using default values in place of asking. When asking, write the options/candidate values into the text as well, so the user can reply directly.

This rule applies in all of the following cases:

• Required parameters and attendees missing: When the parameters required for the operation cannot be inferred from the context (e.g., when creating a meeting, subject/begin_time is missing, attendee attendees is missing, when searching, keywords is missing), you must ask in text; for other non-required parameters (location, meeting room, etc.), when the user has not explicitly specified them, do not ask further and use the default value;end_time(duration) is missing, do not ask further, default duration 1 hour (begin_time + 1h); words that merely describe the attendance method or action (such as "video conference / hold a meeting / remote access") do not constitute a valid subject, treat them as missing and ask in text; do not use them as the subject to create directly
• Multiple candidates require the user to choose: When a search/query returns multiple matches, or the wecomcli-contact skill finds multiple candidates with the same name
• The scope of the operation needs confirmation: For example, when changing a meeting room and multiple bookable candidates are found, the user needs to select a specific one

Constraints on text inquiries：

• The options/candidate suggestions listed should be 2 to 4as appropriate. When there are more than 4 candidate options (such as candidates with the same name, multiple matching meetings), list the 4 most relevant ones and prompt the user to further narrow the scope (by entering more precise keywords / full name / specific time); do not list 5 or more candidates all at once.
• When asking about time, the candidate times listed must be specific times precise to the minute(such as "tomorrow 14:00", "the day after tomorrow 09:30"); it is forbidden to give vague time options such as "morning/afternoon/evening/midday/after work/before getting off work"—vague options will cause the user to still need a second follow-up asking for the specific time after replying, so you must ask once for the precise time that can be directly set as begin_time the exact time of.

For the specific question wording and candidate options for each scenario, see the reference documentation for the corresponding operation.

Rule 4: Permission determination is left to the API

• Do not preemptively block cancellation / meeting updates based on "whether it was created by the user themselves", and do not distinguish created_meetings / attended_meetings—directly execute cancel / update; whether the operation is possible is determined by the API return result.
• A success return means the operation is complete; a permission-type error return means the current user has no permission to operate on this meeting, so inform the user and suggest contacting the meeting organizer.

Rule 5: Input security handling

• When what the user provides is a name, it must go through 读取 wecomcli-contact 技能 search verification before it can be converted to a userid.Forbiddento directly concatenate a name into a userid,Forbiddento fabricate from memory or guesswork. Reason: the string entered by the user may not correspond to a real employee (names are not unique, the person may have left, etc.); direct concatenation will cause messages to be sent to the wrong person or meetings to be created containing invalid attendees, and such errors cannot be intercepted by the API at call time.

Rule 6: Error retry limit

• After the same operation fails, retry at most 2 times. If it still fails after two retries, stop automatic operation, output complete error diagnostic information to the user, and wait for manual intervention.
• Different error types should use different strategies: network timeouts can be retried; insufficient permissions/parameter errors should not be retried (retrying is ineffective).

Long-term memory principles: personalized information such as the user's frequently used attendee combinations (e.g., "Product Team" = Zhang San + Li Si), once explicitly specified for the first time, should be remembered within the current session to reduce repeated questioning. If the current session does not support cross-session persistent memory, then keep the memory within this session; after the session ends, the preference is cleared, and it is sufficient to clarify again next time it is used. (Meeting duration is not included here: when the user does not specify it, it always defaults to 1 hour, no follow-up is asked, and there is no need to remember duration preferences.)

Invocation format

Use the wecom-cli tool to invoke according to the following format

wecom-cli meeting [action] --json '{"key": "value"}'

• meeting action：create、list、get、search、cancel、update、original get
• --json: JSON parameters, wrap withsingle quotesto wrap

Operations reference

The operations reference documentation is a detailed description of commonly used operations.Before executing an operation, be sure to read the corresponding documentation first.

Operations reference	Description
meeting-create	Create a meeting and confirm the details
meeting-list	Query the meeting list (list + get)
meeting-search	Search meetings by keyword
meeting-cancel	Cancel a created meeting
meeting-update	Update information for a created meeting (subject, time, attendees, location, etc.)
meeting-original-get	Query the original meeting transcript (sentence-by-sentence original speech, different from the summary)

Context passing table

Operation	Extract from the return	Used for
search	meetings[].meeting_id	get Check details,cancel Cancel meeting
list	created_meetings[].meeting_id / attended_meetings[].meeting_id	get Check details,cancel Cancel meeting
search	meetings[].meeting_id(for recurring meetings add meetings[].sub_meeting_id）	original get Fetch the original meeting transcript
list	created_meetings[].meeting_id / attended_meetings[].meeting_id(for recurring meetings add the corresponding sub_meeting_id）	original get Fetch the original meeting transcript
list	created_meetings / attended_meetings	When displaying the meeting list, distinguish "created by me" from "attended by me" (not used for permission judgment for cancellation/update)
wecomcli-contact skill search	userid（wo prefix)	create of the attendees array
get	meeting_status	Determine meeting status ("init" / "started" / "end"）
get	repeat_rule	Determine whether it is a recurring meeting (non-empty means recurring meeting): when matched, cancel/update are both unsupported; inform the user and guide them to operate in the WeCom client
create	meeting_id	Meeting unique identifier
search / list + get	Meeting ID (search takes meetings[], list takes created_meetings[]/attended_meetings[]）、repeat_rule	update locating and recurring meeting determination (if a recurring meeting is matched, updates are not supported)

Error handling

Principle: tell the userwhat went wrong + what can be done + alternative options. Silent failure is prohibited. Retry at most 2 times; after exceeding that, stop automatic operations.

Error scenario	Possible cause	Recovery suggestion
The interface returns insufficient permissions (canceling/modifying by a non-initiator)	The current user is not the meeting initiator	Execute directly and judge based on the return; when a permission error is returned, inform the user that they do not have permission to operate, suggest contacting the meeting initiator; do not retry
Time validation failed	begin_time earlier than the current time	Prompt the user to reselect a future time point; do not retry, wait for the user to correct it
Parameter format error (meeting_id)	meeting_id was mistakenly passed a 9-digit meeting number	Check ID source: [correct] "meeting_id": "mtkSFfCgNxxxxxxx"(long string); [incorrect] "meeting_id": "123456789"(the 9-digit meeting number is meeting_code and cannot be used as meeting_id); do not retry
Parameter format error (attendees)	attendees format is incorrect	Check format: [correct] "attendees": [{"userid": "woxxx"}]; [incorrect] "attendees": ["woxxx"](flat string arrays are not accepted) or "attendees": ["张三"](names are not accepted); when the user provides a name, resolve it via 读取 wecomcli-contact 技能 to userid
Search/list has no results	time range or keywords do not match;or the "meeting" the user is looking for is actually a calendar event rather than a meeting with an online meeting link	First suggest expanding the time range or modifying the keywords and retrying; at the same timeproactively 读取 wecomcli-calendar 技能 use the same keywords to search the calendar(in WeCom, "meetings" have two carriers: "meetings with an online meeting link" and "calendar events"; meetings where a team gathers together often fall under calendar events rather than meetings). If there is a match, present it as well and explain "this is a calendar event"; if there is still no result, then inform the user that neither has it
Network timeout	Unstable network	Wait and retry, up to 2 times; after 2 times, prompt the user to try again later
2 consecutive failures	Root cause unknown or persistent issue	Stop automatic retries, output the complete error message, and suggest that the user contact an administrator or operate manually

Output quality standards

A good output should meet the following conditions:

• Meeting list: each item displays only three fields: topic, time, and attendee names (excluding status labels, attendee count, location, meeting number, join link, etc.), sorted in ascending order by start time. See "Meeting List Display Specifications" below for details
• Attendee display: use the attendees[].name field returned by the API as-is (keep it completely consistent with the format returned by the API; if it returns zhangsan(张三) , then display zhangsan(张三)), do not display userid
• Meeting details: include key fields (topic, time, attendee names; do not display the meeting number or join link)
• Operation result: clearly inform success/failure and the reason; after a successful operation, display the latest status

Unacceptable outputs:

• Directly displaying userid instead of names
• Failing silently when encountering an error, without giving the user any prompt

Output format specifications

Attendee name format [REQUIRED]: in all scenarios that display attendees (creation feedback, list, single-item details, etc.), names must alwaysuse the attendees[].name field returned by the API as-is, keeping it completely consistent with the format returned by the API (if it returns zhangsan(张三) , then display zhangsan(张三)); in the templates below, {人名} all refer to this as-is name.

Time year display [REQUIRED]: the "time" line below omits the year by default and shows only month and day (in the template, {M月D日}); only when the meeting year differs from the current year (cross-year) should the year be added before the month and day, in the format {YYYY}年M月D日 {HH:mm}-{HH:mm}。

Relative date label [REQUIRED]: when the meeting date is yesterday / today / tomorrow, the "time" line adds the relative word before the month and day, in the format {昨天|今天|明天} M月D日 {HH:mm}-{HH:mm}(e.g. 时间：明天 6月11日 14:00-15:00); for other dates, display as {M月D日} {HH:mm}-{HH:mm} .

Creation success feedback [REQUIRED]: After successfully creating a meeting, the output content must contain only three parts: subject, time, and attendees. Outputting any other content and extra sentences is prohibited (do not display fields such as location, meeting room, meeting number, join link, meeting_id, etc., and do not append explanations, suggestions, or pleasantries):

主题：{subject}
时间：{M月D日} {HH:mm}-{HH:mm}
参会人：{人名1}、{人名2}

Meeting list display specification [REQUIRED](applicable to both list/search browsing):

• Do not use markdown tables; output each meeting as an independent item in sequential order, sorted by start time in ascending order.
• Each item displays only three things: subject, time, attendees(do not display status labels, attendee count, location, meeting number, join link, etc.).
• When there are more than 10 items, display only the first 10, and at the end inform the user "There are N more; do you need to view more?"
• Attendee names are taken from the meeting get returned by attendees[].name; only call meeting get to look up the first 10 items to be displayed; displaying userid is prohibited.
• Single item format:

1. {subject}
   时间：{M月D日} {HH:mm}-{HH:mm}
   参会人：{人名1}、{人名2}

2. {subject}
   时间：{M月D日} {HH:mm}-{HH:mm}
   参会人：{人名1}、{人名2}

Single meeting details(when viewing single meeting details, complete fields may be displayed):

- 主题：{subject}
- 时间：{M月D日} {HH:mm}-{HH:mm}
- 参会人：{人名1}、{人名2}（禁止展示 userid）
- 地点：{location}（如有）

Do not display meeting number / join link [REQUIRED]: in any scenario (creation feedback, list, search, single details, etc.),do not display the meeting number (meeting_code) and join link (meeting_link）。

Known limitations

Limitations	Workarounds
Creating/updating/canceling recurring (repeating) meetings is not supported	When a user wants to create recurring meetings such as "repeats weekly/monthly/daily", or initiate an update or cancellation for a meeting identified as recurring (repeat_rule is not empty), directly inform the user that this is currently not supported and guide the user to operate manually in the WeCom client; using methods such as creating multiple single meetings in bulk or passing undisclosed parameters to bypass this is prohibited
Replying to / declining meeting invitations (RSVP) is not supported	This skill does not support replying to received meeting invitations with accept / decline / tentative, etc. (including "decline this meeting", "will not attend", "politely decline the invitation", etc.). When the user has this need, inform them that this skill does not support it, and suggest operating directly on the meeting invitation in the WeCom client, or notifying the meeting organizer via message
Attendee limit is 100 people	attendees The array must not exceed 100 userids
Duration limit is 24 hours	begin_time and end_time The interval must not exceed 24 hours. When a request for a single meeting exceeding 24h occurs, directly inform the user that it is not supported and refuse, and do not split it into multiple meetings or bypass it on your own; if the user truly needs a multi-day arrangement, create them separately only after the user clearly specifies the split requirements
Batch query limit is 10	meeting get At most 10 meeting_ids per call; if exceeded, calls must be made in multiple batches (split into batches of ≤ 10, then merge the results)
list does not include meeting_status	An additional call to meeting get is required to obtain the meeting status

Quick reference

API comparison

Function	meeting create	meeting list	meeting get	meeting search	meeting cancel	meeting update	meeting original get
Purpose	Create meeting	Query meeting list	Get meeting details	Search meetings by keyword	Cancel meeting	Update meeting information	Query meeting transcription original text
Prerequisites	Must first obtain userid	None	Must first list/search to get meeting_id	None	Must first confirm meeting_id	Must first confirm meeting_id	Must first list/search to get meeting_id

Parameter quick reference table

API	Core parameters
meeting create	subject(required),begin_time(required),end_time(required),attendees(object array [{"userid": "woxxx"}]）、location(location text; for meeting rooms must use meeting_room_id, only non-meeting-room text writes location）、meeting_room_id(meeting room ID, passed when booking a meeting room, from 读取 wecomcli-calendar 技能 meeting room query),description、timezone(format {"timezone_id": "Asia/Shanghai", "timezone_offset": 28800}）
meeting list	begin_time、end_time(both optional, must be passed together or omitted together),cursor、limit
meeting get	meeting_ids(required, object array, format [{"meeting_id": "xxx"}]，maximum 10 per call, exceeding requires multiple batched calls; for recurring meetings add sub_meeting_id）
meeting search	keywords(required, string array),begin_time、end_time、cursor、limit(fixed pass 20）；keywords can match meeting subject, attendee names, meeting minutes content, meeting room name, and other information
meeting cancel	meeting_id(required); canceling recurring meetings is not supported
meeting update	meeting_id(required),subject、begin_time、end_time、add_attendees/remove_attendees(object array [{"userid": "x"}]）、location(location text; for meeting rooms must use meeting_room_id）、meeting_room_id(passed when changing meeting room, must first confirm via rooms search ; updating recurring meetings is not supported status=bookable）、description; updating recurring meetings is not supported
meeting original get	meeting_id(required,mt long string),sub_meeting_id(passed for a specific occurrence of a recurring meeting),media_index(which segment, starting from 0,defaults to returning all segments if not passed, pass only when the user explicitly specifies "segment N" N-1）、cursor、limit(default 100, maximum 500)