Before executing any

wecom-cli

commands, you must first read and complete the public pre-checks of the

wecomcli-shared

skill.

• Schedule / create events (including in-person face-to-face meetings only, i.e., arrangements without online meeting links)
• View / browse events (e.g., "What arrangements do I have today?", "Check this week's events")
• Search events (find a specific event by keywords, organizer, or attendees)
• Update / modify events (change time, location, add/remove attendees, switch meeting rooms; recurring events are not supported for updates)
• Cancel events (recurring events are not supported for cancellation)
• Check availability / schedule a common free time slot for multiple people
• Book meeting rooms, check meeting room availability, check office buildings

• Create, update, or cancel recurring events (weekly/monthly/daily repeats) → Not supported; guide users to operate manually in the WeCom client
• Respond to / reject event invitations (accept/reject/tentative, including phrases like "Reject this event" "Will not attend") → Not supported; guide users to operate in the WeCom client or message the initiator directly

• If the user wants to create a meeting with an online meeting link (requiring meeting ID/join link, remote or video attendance) → Use

  wecomcli-meeting

  instead (creating a meeting will generate an event simultaneously, no need to create another in this skill)
• If the user only mentions phrases like "hold a meeting/schedule a meeting/arrange a meeting/XX meeting" without specifying whether it's an event or an online meeting (creation scenario) → You must first use text to ask for disambiguation (fixed question: "Do you need to create an event or a meeting?", ask the user to reply with "Event / Meeting"), and must not make assumptions to create directly
• If the user needs a meeting that supports both in-person and remote attendance (e.g., "Hold offline, remote colleagues join online") → It includes an online meeting link; use

  wecomcli-meeting

  instead
• Only provides location / meeting room number (e.g., "Hold a meeting in 1605" "Book a meeting room for the meeting") → Does not constitute "clearly an event"; you still need to use text to ask for disambiguation, and cannot skip the question just because a location is provided
• Ambiguous expressions in query scenarios (e.g., "What meetings do I have recently / What meetings are there") → Strictly prohibited from asking for clarification; check both events and meetings and display the merged results; only switch to

  wecomcli-meeting

  to check only meetings when the user clearly mentions "online meeting / video meeting / join link / meeting ID / Tencent Meeting / remote attendance"

Principle for Choosing Browse vs Search: When the user mentions event subject keywords, use search; when only time/date is provided without event subject keywords, you must use list browsing (

list

). Retrieve single event details only when additional information like recurrence rules or meeting links is needed.

Fixed Question and Options [CRITICAL]: When confirming disambiguation, the question and options must be used exactly as written — the fixed question is

"Do you need to create an event or a meeting?"

, and the fixed options are

Event

/

Meeting

; do not rephrase the question, add/remove or rephrase options, translate, or design other expressions (e.g., "online meeting / virtual meeting / video meeting / offline meeting").

Do you need to create an event or a meeting? (Please reply: Event / Meeting)

• The words "meeting" / "conference" / "hold a meeting" do not constitute "clarity" [CRITICAL]: These words only indicate the need to meet and discuss, and do not specify whether it's an event or a meeting. Do not default to creating an event in this skill just because the query contains "meeting", nor default to a meeting — as long as it's not clear, always ask for clarification via text first before routing. Only stay in this skill when there are pure offline signals like "meet in person" "create an event".
• If the user replies "Event" → Stay in this skill and create the event following the "Event Scheduling Workflow".
• If the user replies "Meeting" → Switch to

  read wecomcli-meeting skill

  to create the meeting (creating a meeting will generate a corresponding event simultaneously, no need to create another event in this skill).
• If the user has clearly specified (e.g., "meet in person" "create an event" = event; "send a join link" "need meeting ID" "remote attendance" = meeting) → Route directly without asking for clarification.
• If the meeting supports both in-person and remote attendance (e.g., "Hold offline, remote colleagues join online") → Since it includes an online meeting link, it belongs to the wecomcli-meeting skill: creating a meeting will generate an event simultaneously, no need to create another event in this skill.
• Only provides location/meeting room number (e.g., "Hold a meeting in 1605" "Meet in Building A's meeting room" "Book a meeting room for the meeting") does not constitute "clearly an event" — remote access may still be needed in the meeting room, so it's still unknown whether it's an event or a meeting; you must use text to ask for clarification, and cannot skip the question just because a location is provided.

cancel

create

1. Locate first, then determine meeting association: Both

   search

   /

   list

   returns include the

   meeting

   field. After locating the target event, directly check

   meeting.meeting_code

   — non-empty means "event in meeting form with online meeting link", empty means pure event; no need to retrieve event details again (only retrieve if additional fields like

   repeat_rule

   are needed).
2. Pure event → Use the update event intent in this skill's routing table to change the time; do not use cancel + create.
3. With meeting link → Switch to

   read wecomcli-meeting skill

   , pass

   meeting.meeting_id

   to

   meeting update

   to change the time (retain meeting link and attendees), no need to re-search and locate in wecomcli-meeting.

Root Cause:

create

can only create pure events and cannot re-generate meeting links (can split but not merge). Using cancel + create will permanently lose the meeting link, so rescheduling must always use update.

schedule_id

Browse vs Search: With event subject keywords → Use search (no need to ask for time); only time/date provided without subject keywords → Use list browsing (

list

), do not feed the date as

keywords

to

search

. List browsing already returns

repeat_rule

, no need to retrieve single event details additionally to determine if it's a recurring event.

Query Disambiguation (Check both events and meetings for ambiguous queries) [REQUIRED]: Strictly prohibit asking the user "Is it an event or a meeting" via text in query scenarios — disambiguation via text only applies to creation; queries must be processed directly according to the following rules without asking for clarification. Judgment is divided into two independent dimensions, do not confuse them:

Dimension 1: Which side to check (Event / Meeting / Both)

• Clearly online meeting → When the user clearly mentions exclusive features of online meetings like "online meeting / video meeting / join link / meeting ID / Tencent Meeting / remote attendance", switch to

  read wecomcli-meeting skill

  to check only meetings.
• Clearly event / arrangement → When the user clearly mentions event-related content (e.g., "event / arrangement / my arrangements / calendar / What arrangements do I have today" without online meeting features), check only events.
• Ambiguous expression cannot be determined (e.g., "meeting / XX meeting / XX conference / hold a meeting / What meetings do I have recently / What meetings are there / Find XX conference", which could be either an event or a meeting) → Check both events and meetings: Check events, and

  read wecomcli-meeting skill

  to check meetings.

Dimension 2: Use

search

or

list

for each side (independent of Dimension 1, judge each side separately)

• With subject/name keywords (e.g., "Find XX conference" "When is the project review?") → Use

  search

  for that side (pass the keywords to

  keywords

  ).
• Only time/date or general browsing without keywords (e.g., "What meetings do I have recently" "What arrangements do I have today") → Use

  list

  for that side; do not feed the date as

  keywords

  to

  search

  .
• Even if "check both sides", choose for each side according to this dimension: use

  search

  for both sides when keywords are provided, use

  list

  for both sides when only time/general browsing is provided.

Merged Display: When checking both sides, merge the results and display uniformly — divide into "(Meeting)" (from meeting side, or events with non-empty

meeting.meeting_code

) and "(Event)" (pure events with empty

meeting_code

) based on whether they contain online meeting links; deduplicate by "subject + time" if the same meeting appears on both sides, and add a summary at the end "Total N sessions, including X meetings and Y events".

• This disambiguation only applies to queries; creation scenarios still use text to ask for clarification as per "Event vs Meeting" above.

• First locate the event (use search when event subject keywords are provided; use list browsing

  list

  when only time/date is provided without subject keywords, do not feed the date as

  keywords

  to

  search

  ), determine if it's a recurring event — Recurring events are not supported for updates, inform the user and guide them to operate in the WeCom client (see "Known Limitations"), do not patch by updating each session individually or change to cancel + create. For regular events, collect the modification content and execute the update; do not pre-block modification based on "whether created by the user", execute the update directly and judge whether it can be modified based on the tool's return result (success returns updated

  detail

  , permission error returns an error; inform the user and suggest contacting the creator in this case).
• Changing time/location, adding/removing attendees, switching meeting rooms all use update, do not cancel and re-create. When switching meeting rooms, first confirm the new meeting room has

  status=bookable

  via

  rooms search

  , then pass the new

  meeting_room_id

  to the update (see calendar-meeting-room).
• Updating the time of an event with an online meeting link (non-empty

  meeting

  in the location result) is not done in this skill's update, switch to

  read wecomcli-meeting skill

  instead (see "Must Identify Meeting Association Before Rescheduling / Re-creating Events" above).
• The complete process for updating events is shown in calendar-update.

• Event (Schedule): A single event in the calendar system, including attributes like subject, start/end time, attendees, etc.
• All-day Event:

  is_all_day=true

  , only occupies by date, and the end date is included in the event.
• Recurring Event:

  repeat_rule.is_repeat=true

  , occurs repeatedly according to rules.
• Attendee: Identified by

  userid

  (prefix

  wo

  ). When the user provides a name, resolve it to

  userid

  via

  read wecomcli-contact skill

  .
• FreeBusy: Query whether attendees have event occupancy in the specified period.
• Location: The location of an event is a free text field (

  location

  ). When the user provides a company meeting room as the location, it must be booked via meeting room query (

  rooms search

  ) and occupied with

  meeting_room_id

  (see calendar-meeting-room); do not only write the meeting room name into

  location

  ; when the user provides a non-meeting room ordinary text location, write it directly into

  location

  .
• Meeting Room / Building: Physical space resources (unrelated to online meeting links). Use

  buildings list

  to check accessible office buildings,

  rooms search

  to check meeting room availability, pass

  meeting_room_id

  to atomically occupy when creating events, and pass

  meeting_room_id

  to re-book when updating events. For details, see calendar-meeting-room.
• Timezone: Each event has a

  timezone

  (

  timezone_id

  +

  timezone_offset

  ). The

  begin_time

  /

  end_time

  of an event is the wall time in that timezone, and the backend does not perform conversion — the incoming and returned time strings are interpreted according to the event's timezone; do not convert them to UTC+8 or local time on your own.

• All input parameters for "member userid lists" such as

  attendees

  /

  add_attendees

  /

  remove_attendees

  /

  userids

  /

  has_attendees

  must be object arrays in the format

  [{"userid": "woxxx"}, {"userid": "woyyy"}]

  ; names or flat string arrays are not accepted.

• organizer

  (search by organizer) is a single value, pass a userid string (prefix

  wo

  ), not an array.
• When the user provides a name, resolve it to the corresponding userid via

  read wecomcli-contact skill

  ; when there are multiple candidates, list them for the user to choose, do not guess on your own.
• Prohibit using names as userids, prohibit making up userids based on memory or guesses.
• Reason: The calendar API does not support matching attendees by name; passing names will cause silent failures or invitations to the wrong people.

• When creating or canceling events, execute directly once the parameters are ready; no need to display a summary to the user or ask for confirmation.
• Prohibit exposing userid when returning results; only display names.
• Reason: The upper-layer interaction has already fully displayed the operation content and completed confirmation; displaying it again here will cause redundancy.

• Missing required parameters and attendees: When the required parameters for creating events (

  subject

  /

  begin_time

  /

  end_time

  ) and attendees

  attendees

  cannot be inferred from the context, you must ask via text; for other non-required parameters (e.g., location), do not ask specifically if the user does not specify, use default values directly
• Multiple candidates require user selection: Multiple matching events returned by search, multiple candidates with the same name found by wecomcli-contact skill
• Need to confirm operation scope: e.g., multiple bookable candidates found when switching meeting rooms, need the user to select a specific one
• Conflict handling: Time conflict found during availability check, need user decision

• It is advisable to list 2~4 options / candidate suggestions. When there are more than 4 optional candidates (e.g., candidates with the same name, multiple matching events), list the top 4 most relevant ones, and prompt the user to narrow the scope further (enter more precise keywords / full name / specific time); do not list 5 or more candidates at once.
• When asking for time, the candidate times listed must be specific times accurate to the minute (e.g., "Tomorrow 14:00", "Saturday 10:30"); prohibit giving vague time options like "morning/afternoon/evening/noon/after work starts/before work ends" — vague options will require a second inquiry after the user replies, so you must ask for a precise time that can be directly set as

  begin_time

  in one go.

• Time format: Must be

  YYYY-MM-DD HH:mm:ss

  ; reject vague expressions and pass them directly as parameters (e.g., "tomorrow" cannot be passed directly, must be resolved to a specific time first)
• Time order:

  end_time

  must be later than

  begin_time

  ; reject events with zero or negative duration
• userid format: Must be a string with prefix

  wo

  ; pure numbers or Chinese names are not accepted
• Historical time: Prohibit creating events that are completely before the current time

• When the user provides a name, it must be verified via

  read wecomcli-contact skill

  search before being converted to userid.
• Prohibit directly using names as userids, prohibit making up userids based on memory or guesses.
• Reason: The string input by the user may not correspond to a real employee (non-unique name, resigned, etc.); directly using it as a userid will result in sending event invitations to the wrong people, and such errors cannot be intercepted by the API during calls.

This table describes the data flow contract between interfaces; the first column "Source Operation" is the business semantics; the complete parameters and field definitions for each operation are shown in the corresponding reference.

schedules[].schedule_id

schedule_list[].schedule_id

schedules[].attendees[].name

schedules[].creator_name

next_cursor

has_more

userid

wo

attendees

add_attendees

remove_attendees

userids

has_attendees

[{"userid": "woxxx"}]

organizer

repeat_rule

is_repeat=true

search

list

get

meeting.meeting_code

get

meeting.meeting_id

meeting update

meeting cancel

wecomcli-meeting

schedules[].schedule_id

schedule_list[].schedule_id

schedule_list[].repeat_rule

slots[]

available_users

available_count

busy_users

attendees

rooms search

target[].room.meeting_room_id

recommendations[].meeting_room_id

meeting_room_id

meeting_room_id

Principle: Tell the user what went wrong + what can be done + alternative solutions. Prohibit silent failures.

organizer

has_attendees

slots

available_count < total_count

• Event list: Sorted in ascending order of start time, each event is output as an independent entry in order (prohibit markdown tables), each entry only includes subject, time, attendees; only display the first 10 entries if there are more than 10
• Attendee display: Use the

  attendees[].name

  field returned by the interface as-is (completely consistent with the format returned by the interface, e.g., display

  zhangsan(张三)

  if returned as

  zhangsan(张三)

  ), do not display userid
• Operation results: Clearly inform success/failure and reasons, display event summary after successful operation
• Error prompts: Include problem description + recovery suggestions + alternative solutions, do not expose technical error codes

• Directly display userid instead of name
• Silent failure when encountering errors, no prompt to the user
• Display internal schedule_id

attendees[].name

zhangsan(张三)

zhangsan(张三)

{name}

{month-day}

M月D日

{YYYY}年M月D日 {HH:mm}-{HH:mm}

{yesterday|today|tomorrow} M月D日 {HH:mm}-{HH:mm}

Time: Tomorrow June 11 14:00-15:00

{month-day} {HH:mm}-{HH:mm}

Subject: {subject}
Time: {month-day} {HH:mm}-{HH:mm}
Attendees: {name1}, {name2}

Subject: {subject}
Time: {month-day} {HH:mm}-{HH:mm}
Attendees: {name1}, {name2}

• Prohibit using markdown tables; each event is output as an independent entry in order, sorted in ascending order of start time.
• Each entry only displays three items: subject, time, attendees (do not display location, reminder, schedule_id, etc.).
• Only display the first 10 entries if there are more than 10, and inform at the end "There are N more entries, do you need to view more?".
• Display meetings / events in two separate sections: Judgment is based on whether the event has a meeting link — events with non-empty

  meeting.meeting_code

  are classified as "(Meeting)", empty / non-existent are classified as "(Event)" (search/list/get returns all include the

  meeting

  field, which can be directly judged). Only when both "(Meeting)" and "(Event)" categories exist in the current results should the results be divided into "(Meeting)" and "(Event)" sections for separate display: list the "(Meeting)" section first, then the "(Event)" section; each section is sorted in ascending order of start time, with each entry only displaying subject/time/attendees; add a summary at the end "Total N sessions, including X meetings and Y events". When the results are of a single category (all meetings or all events), do not divide into sections, do not add "(Meeting)" / "(Event)" titles, display directly as a normal list.
• Sectioned format:

(Meeting)
1. {Subject}
   Time: {month-day} {HH:mm}-{HH:mm}
   Attendees: {name1}, {name2}

(Event)
1. {Subject}
   Time: {month-day} {HH:mm}-{HH:mm}
   Attendees: {name1}, {name2}

timezone_offset != 28800

{HH:mm}-{HH:mm} ({Chinese region name} UTC±N)

14:00-15:00 (New York Time UTC-5)

• UTC±N

  is calculated by

  timezone_offset / 3600

  .
• The Chinese region name is derived from

  timezone_id

  (e.g.,

  America/New_York

  → New York Time); omit the Chinese name if

  timezone_id

  is empty, only keep

  (UTC-5)

  .
• No label for UTC+8 (

  timezone_offset = 28800

  , including

  Asia/Shanghai

  ,

  Asia/Singapore

  , etc.), keep as is.
• Applicable to the "Time" line of single event summaries, event lists, creation/update success feedback; not applicable to

  slots

  in freebusy (displayed in the user's own timezone).