CRITICAL — Before executing any

dws

operation, MUST first use the Read tool to fully read

dingtalk-shared

. This lightweight file contains the global execution contract, safety baseline, and on-demand loading navigation for shared references; do not preload all its references.

For common paths, execute directly according to this file; do not pre-read the large and comprehensive calendar.md. Only read the corresponding sections on demand when recurring schedules, responding to invitations, sharing/ACL, attachments, calendars, or low-frequency parameters cannot be located from this file; read 03-meeting.md only for the scope and failure closure of meeting room booking.

When the following intents are matched, must execute in the corresponding SOP order; forbidden to skip steps, replace commands, or fabricate userId/eventId. Every command must include

--format json

; time parameters must be ISO-8601 (e.g.,

2026-07-03T14:00:00+08:00

).

1. Preferred script (mandatory):

   python scripts/calendar_today_agenda.py today|tomorrow|week

   (aggregates today's agenda).
2. Fallback CLI (mandatory): when the script is unavailable,

   dws calendar event list --start "<起始ISO>" --end "<结束ISO>" --format json

   ; if

   --start

   /

   --end

   are not provided, the default is today (00:00:00~23:59:59). When

   nextCursor

   is returned, continue paging until the cursor is empty; do not treat a single successful page as a complete query.
3. Parse (mandatory): extract the real

   eventId

   ,

   attendees[]

   , and

   start/end

   ; extract only what is needed; forbidden to paste the entire JSON verbatim. When the user asks for a summary or count, complete the aggregation locally and only output per-group counts and necessary details, to avoid filling the reply line by line and causing the latter half to be truncated.

event list

1. Resolve attendees (mandatory): for each name, run

   dws aisearch person --query "<姓名>" --dimension name --format json

   and take

   userId

   ; join multiple people with commas.
2. Execute (mandatory):

   dws calendar event create --title "<主题>" --start "<ISO>" --end "<ISO>" --attendees <userId1,userId2> --format json

   (add

   --location

   /

   --desc

   /

   --rooms

   as needed).
3. Verify (on demand once): get the event ID from

   result.id

   in the creation response (downstream parameter semantics call it

   eventId

   ). If the creation response already contains the title, description, and time range the user asked for, reuse it directly; do not run an extra list just to 'take another look'. Only run

   event get

   /narrow-window

   event list

   once when the response is missing fields, the user explicitly asks to verify, or the later state has changed.

roomId

1. Resolve object (mandatory): name →

   dws aisearch person --query "<姓名>" --dimension name --format json

   to get

   userId

   ; for meeting room use

   roomId

   .
2. Converge time range (mandatory):

   --start

   /

   --end

   must be explicitly provided or converged by the user; if the time range is unclear, must ask first; forbidden to default to an all-day window.
3. Execute (mandatory):

   dws calendar busy search --users <userId1,userId2> --start "<ISO>" --end "<ISO>" --format json

   (for rooms, use

   --rooms <roomId...>

   , can be passed together). Forbidden to use

   event list

   to scan schedules instead of a busy/free query.
4. Free slots (mandatory): use

   python scripts/calendar_free_slot_finder.py

   to find common free time.

event list

busy search

• Verify the request first, then clean up resources: first extract and temporarily store the details, conflict pairs, attendees, meeting rooms, and verification conclusions the user asked to see from the structured responses; even if temporary resources are deleted afterward, the final reply must present these results item by item. A successful tool call does not mean the results have been delivered to the user.
• Target verification must name conclusions: when conflict/busy-free/search returns many records or the output is truncated, you must converge and verify by the current case's title,

  eventId

  , person, or resource ID; you cannot just say 'ran the check'. For example, a conflict task must clearly state the overlapping start/end time of targets A/B and whether back-to-back adjacency is excluded.
• New event + new meeting room: prefer completing in two steps: when the user asks from the start to create an event and book a room, and there is no intermediate operation depending on a created

  eventId

  , first run

  room search

  to get the real

  roomId

  , then use one

  event create ... --rooms <ROOM_ID>

  to complete creation and booking; attendees can also be included via

  --attendees

  . Only use

  room add

  when the event already exists, the user asks to see the event before booking, or the one-step creation failed; do not perform the two writes 'create → room add' without reason.
• Multi-turn event tasks must retain the

  eventId

  ; subsequent adding/removing attendees, booking a room, changing rooms, modifying the description, and deleting are all executed against the same

  eventId

  ; do not recreate duplicate events.
• When the user explicitly says 'help me book an available meeting room', after

  room search

  returns available rooms, directly select the first

  roomId

  that is bookable and does not require custom approval and execute

  room add

  ; do not throw the choice back to the user and stall the task.
• Booking a room for an existing event:

  dws calendar room search --start ... --end ... --format json

  →

  dws calendar room add --event <EVENT_ID> --rooms <ROOM_ID> --format json

  → verify with

  event get

  or

  room/busy

  .
• Changing a meeting room: first

  room delete --event <EVENT_ID> --rooms <OLD_ROOM_ID>

  , then

  room add --event <EVENT_ID> --rooms <NEW_ROOM_ID>

  , and finally re-check; do not only update

  --location

  .
• Attendee changes use

  attendee add/delete

  , event description changes use

  event update --desc

  , and event deletion uses

  event delete --id

  . If the user's current message explicitly requests deletion/cancellation, execute directly; otherwise confirm first.
• Deleted terminal state: verify once on demand: when the user explicitly asks to 'confirm deletion/no residue', after

  event delete

  succeeds, perform a narrow-window active list check using the original

  eventId

  , title, calendar, and original start/end time; for ordinary 'cancel after done', structured deletion success is the terminal state, with no extra get/list.

  event get

  may still return historical objects or tombstones; unless

  status=cancelled

  truly exists in the response, do not claim 'status changed to cancelled'.
• When a script fails or parameters are incomplete, immediately fall back to explicit

  dws calendar event/attendee/room

  commands; do not stop at 'I want to view the usage'.
• All dws commands must include

  --format json

  ; query times must explicitly use

  --start

  /

  --end

  .

• Video meeting initiation / join links / inviting to meeting / in-meeting controls → currently not supported by the CLI; please complete these in the DingTalk client
• Post-meeting summaries / to-dos → switch to

  dingtalk-minutes

• Resolving attendees by person name → first use

  dingtalk-aisearch

• Local intent disambiguation; Short flows.