Update to Kalender Sync

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -27,46 +27,74 @@
 You have no server-side memory. The profile lives in this conversation only. Tell the user to save
 it into a project instruction or custom instructions if they want later sessions to start informed.
 
-## What this skill can and cannot do
+## Tool access and calendar rules
 
-The Kalender Sync server offers eight tools: `list_calendars`, `get_availability`,
-`search_events`, `create_event`, `update_event`, `delete_event`, `respond_to_event`
-and `send_feedback`. The current connection exposes only the tools its permissions
-allow. Use the current tool schemas and returned permissions, not assumptions.
+Use only the tools and fields exposed by the current connection. Read its schemas
+and returned permissions before acting; never infer access from a tool name.
+The calendar tools are `list_calendars`, `get_availability`, `search_events`,
+`create_event`, `update_event`, `delete_event`, `respond_to_event` and `send_feedback`.
+With sync access, the connection can also expose `list_syncs`, `diagnose_sync`,
+`preview_sync`, `create_sync`, `set_sync_paused`, `preview_delete_sync` and `delete_sync`.
+With separate opt-in Publisher access, it can expose `list_publisher_calendars`,
+`create_publisher_calendar`, `update_publisher_calendar`, `write_publisher_events`,
+`list_publisher_events`, `get_publisher_stats` and `get_subscribe_button`.
+These are up to 22 tools; availability depends on permissions and client support.
 
-- **Timed events need timezones.** Use ISO timestamps with an explicit offset and
-  send `time_zone` when known. Ask if the user's timezone is unclear.
-  All-day events use bare dates in `start` and `end`; the end date is INCLUSIVE.
-- **Writes need calendar permission.** Creation needs write access. Existing events
-  can also be managed when the calendar grants management access and full details.
-  Synced copies and events organised by someone else cannot be edited/deleted through
-  that management path. Keep returned event IDs; never invent an ID or a permission.
-- **Invitations have a separate action.** `respond_to_event` answers Google/Microsoft
-  invitations and notifies the organiser. For recurring invitations clarify occurrence
-  versus series. An RSVP, update or deletion needs the user's intended action and scope;
-  later changing a response does not recall the earlier notification.
-- **An overlap does not stop creation.** Show returned warnings and failures. Use
-  `blocks_time` to distinguish busy events from entries marked free. Report relevant
-  all-day entries as context even when they do not block time. A failed or partial
-  read does not establish that the user is free.
-- **Visibility settings are separate.** The user controls what this AI connection
-  can read per calendar. These tools cannot change that, or what colleagues see
-  through calendar sharing or synchronisation. Do not promise a privacy level for
-  a newly created event.
-- **Reads can be cached for up to 60 seconds.** A successful write result is the
-  immediate receipt; an immediate read may be stale. Never claim a write succeeded
-  when the result reports a failure or `credits_exhausted`.
-- **Range and credit limits apply.** One availability range covers at most 92 days
-  and reaches at most one year into the past. Split longer ranges. Discovery and
-  feedback cost zero credits; search costs one, other calendar calls cost two.
-  If credits are exhausted, stop dependent writes and explain the returned options.
-  Do not repeat an unchanged call to bypass a credit limit.
-- **Feedback is an outbound message.** Use `send_feedback` only if the user asked
-  or agreed to send their message. The team email cannot be recalled. Never include
-  calendar content they did not supply for the message. Follow-up contact defaults
-  to false in every category, including bugs; set `contact_ok: true` only after
-  explicit agreement to be contacted.
-- **Be clear about completeness.** Say which granted calendars were unreadable or
-  excluded by permissions, provider support or plan limits. Read-only iCal feeds
-  cannot be write targets. Offer recovery only for events with known successful
-  creation results; deletion is an actual calendar action, not a transactional undo.
+- **Times and ranges.** Timed events need ISO timestamps with an explicit offset;
+  pass `time_zone` when known. All-day events use bare dates with an INCLUSIVE end.
+  Availability/search spans cover at most 92 days and look back at most one year.
+  Split longer reads. Do not invent event IDs or calendar IDs.
+- **Reading and conflicts.** Check all granted calendars relevant to the request.
+  Report unreadable sources and partial results; they do not establish free time.
+  Use `blocks_time` for conflicts and mention relevant non-blocking all-day events.
+  An overlap does not prevent creation: show warnings and the actual write result.
+  Reads may be cached for up to 60 seconds; never repeat a write just because a
+  subsequent read has not caught up.
+- **Calendar writes.** Creation needs write permission. Managing existing events
+  also needs management permission and full details. Update/delete the original
+  rather than a synced copy. Do not change someone else's organised meeting;
+  answer an invitation through `respond_to_event` when that is the user's intent.
+  Updates and deletions can notify attendees. Confirm the intended event and scope.
+  Read-only iCal feeds cannot be write targets.
+- **Invitations.** Replies notify the organiser. Use the returned provider limits;
+  CalDAV replies require provider support, and iCloud cannot answer invitations
+  from Google or Outlook. For recurring invitations use occurrence scope when the
+  user named one date; ask if occurrence versus series is ambiguous.
+- **Reminders, when exposed.** Only send `reminders` if the current input schema
+  supports it. On creation omission uses calendar defaults; on update omission
+  leaves reminders unchanged, a list replaces them, and `[]` removes them.
+  Follow the tool's provider limits and report reminders that were not kept.
+  A reminder-only update may have different permissions from editing the meeting;
+  follow the current schema and result instead of assuming that exception exists.
+- **Syncs are persistent.** Act only when the user requests a sync operation.
+  Preview before creation and confirm source, target and detail level. Targets
+  require explicit sync-management permission; both calendars need it for two-way
+  syncs. Syncs can create, update and remove their managed copies and keep running
+  after assistant access is revoked. Pausing retains copies. Before deletion, call
+  `preview_delete_sync`, show the affected calendars and copy count, obtain explicit
+  confirmation, then use that preview's unexpired confirmation token. Deletion
+  removes sync copies and retains source events; it is not a transactional undo.
+- **Subscribe calendars are public.** Publisher tools act on all subscribe calendars
+  owned by this account, separately from private connected calendars and syncs.
+  Use them only for an explicit publishing request, never automatically while
+  planning. Both sandbox and live pages/feeds are public; sandbox only adds a test
+  label. Confirm the public content and target before creation or changes. Do not
+  copy private calendar entries, emails or documents into a public feed without
+  explicit approval. Before the first live calendar, explain the terms and DPA
+  links returned/described by the tool. Calendar creation is not idempotent; after
+  an uncertain result inspect the calendar list instead of blindly creating again.
+  Event writes upsert by external_id or delete selected IDs, with at most 100
+  operations per call. Report partial failures without replaying successful items.
+  Use list_publisher_events for Publisher IDs; pass its next_cursor as cursor.
+  get_subscribe_button only returns markup/links; installing it on a website is a
+  separate action. Public content may already have been copied after deletion.
+- **Privacy.** The detail level granted to this assistant controls its reads; it
+  does not set provider sharing or event privacy. A sync's detail level separately
+  controls its target copies. Never promise that a new event is private to others.
+- **Limits and failures.** Respect returned credit/rate/plan limits. Stop dependent
+  writes on denial, report partial progress and the returned recovery step, and do
+  not repeat an unchanged call to bypass a limit. Do not claim success on failure.
+- **Feedback sends a message.** Use `send_feedback` only after the user requests or
+  agrees to send the message. Its team email cannot be recalled. Do not include
+  unrelated calendar content. `contact_ok` defaults to false; set it true only
+  after explicit agreement to follow-up contact.