Skill instructions
import-schedule7.05 KB
View saved version →
---
name: import-schedule
description: "Take a whole schedule the user pastes in, a term plan, shift rota, course series or project plan, structure it, show every clash with what is already there, enter it in one go, and track created events for removal if requested. Use whenever the user wants many events entered at once."
---
# Enter a list of appointments
Entering forty appointments by hand takes an hour. Prepare the entries together and offer to delete the successfully created events
if the user later asks to remove them.
## Steps
1. Take the list in whatever form it arrives: pasted text, a table, a copied email. Structure it
first and write nothing yet.
2. Show what you understood and name what is missing or ambiguous: end times, timezones, dates
that could be read two ways. Timed entries need timezone-aware timestamps; all-day entries use bare dates
with an inclusive end date.
3. `list_calendars` and settle the target. When more than one calendar is writable, the target has
to be passed explicitly or the write is refused.
4. Call `get_availability` across the period, splitting ranges longer than 92 days.
Show clashes from successfully read calendars together and disclose any incomplete reads.
This matters because overlaps do not block a write, they only produce a
warning after the fact.
5. Show a preview: what will be created, where, and what overlaps. Get one confirmation.
6. Create the approved entries sequentially and heed rate-limit/credit results.
Stop on a limit and report partial progress; a batch size alone does not enforce a rate limit.
7. Report what was created, skipped or failed. If something broke partway, say how many are
already in.
8. Offer to remove everything from this session again with `delete_event`.
## Tool access and calendar rules
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.
- **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.
kalender-sync-setup6.91 KB
View saved version →
---
name: kalender-sync-setup
description: "Go through the user's connected calendars once and establish which is which, so every later planning session works from knowledge instead of guesswork. Use when the user has just connected Kalender Sync, asks what you can see, or when a planning request would otherwise require guessing which calendar is work and which is private."
---
# Set up the calendar context
Run this once, before any planning. Everything else assumes it.
## Steps
1. Call `list_calendars`. Read back every calendar with its provider, whether you can read it,
whether you may write to it, and the detail level the user granted.
2. For any calendar whose name does not make its purpose obvious, call `get_availability` for the
current week and quote two or three real entries so the user can identify it.
3. Go through them one at a time and ask what role each plays: work, personal, club, clients,
family. Do not offer a fixed list, let the user describe it.
4. Ask for core hours, hard stops, and recurring commitments that never move.
5. Report which calendars you may write to. If none are writable and the tool response carries a
`notice`, pass that notice on: it describes something the user can change.
6. Explain what the selected visibility level reveals to this AI connection.
Keep it separate from sharing or sync visibility to other people.
7. Summarise the result as a short profile.
## Important
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.
## Tool access and calendar rules
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.
- **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.
plan-my-day6.46 KB
View saved version →
---
name: plan-my-day
description: "Plan the user's day across all their calendars. Surfaces what is scheduled, finds clashes and impossible transitions, then places the user's priorities into the gaps that actually exist. Use for requests like plan my day, what does my day look like, or help me get through today."
---
# Plan the day
A short morning session. Three to five minutes, and something concrete ends up in the calendar.
## Steps
1. Call `get_availability` for the whole day in the user's timezone, midnight to midnight.
2. Read the day back grouped by calendar, so work and private commitments appear together.
Name any calendar that could not be read.
3. Point out overlaps, especially between different accounts, and transitions that are too tight
given the locations on the entries.
4. Ask for the three things the user most wants to get done, with a rough duration each.
5. Hold those against the free stretches. If they do not fit, say so plainly and ask what drops
rather than inventing time.
6. Propose an order, demanding work early.
7. On approval, `create_event` for each block, each in the calendar matching what it is.
Pass on any overlap warnings.
## Tool access and calendar rules
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.
- **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.
plan-my-time-off7.08 KB
View saved version →
---
name: plan-my-time-off
description: "Turn a handful of leave days into as many days off as possible. Computes the bridge days around public holidays, checks each candidate against every calendar, then enters the absence everywhere it belongs. Use for planning holidays, booking time off, or making the most of remaining leave days."
---
# Plan time off
The session with the clearest payoff: three days of leave becoming nine days off.
## Steps
1. Ask where the user lives (for public holidays), how many leave days they have, and which are
already spoken for. Confirm the relevant year and region. Use verified holiday dates
from the user or an available authoritative source; do not invent school terms.
2. Compute the candidates and rank them by yield: free days gained per day of leave spent.
3. Check the candidate windows with `get_availability`. A year exceeds the 92-day limit, so either
split it into quarters or, better, query only the candidate windows.
4. Hold them against work fixtures: trade fairs, quarter ends, project deadlines. Only calendars actually connected and granted to this AI connection are included.
Do not assume that every calendar shared with the user is accessible here.
5. Present the candidates in order, each with its yield and whatever stands in the way.
6. On approval, create the agreed absence in the specified writable calendars.
Use all-day dates or timed working-hour blocks as agreed, and report the actual results.
## Important
All-day events are supported: use bare dates, with an inclusive end date. The tools
do not set a provider-specific out-of-office type. Apple/iCloud all-day events are
returned as non-blocking context, so discuss a timed busy block if the user needs
working hours to be blocked rather than only an all-day absence marker.
## Tool access and calendar rules
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.
- **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.
plan-my-week6.57 KB
View saved version →
---
name: plan-my-week
description: "Plan the coming week across every calendar. Collects the fixed points, does the capacity arithmetic out loud, names overloaded days before anything is planned into them, then places the week's goals into what is genuinely left. Use for plan my week, weekly planning, or how much time do I actually have next week."
---
# Plan the week
The longest session, and the one with the strongest moment: an honest number.
## Steps
1. `list_calendars`, then `get_availability` for the seven days. One call is enough, a week is far
inside the 92-day limit.
2. Collect the fixed points grouped by calendar. Where the same appointment appears in two
calendars because they are synced, count it once.
3. Do the arithmetic out loud: how many hours are committed, how many of those are appointments
with other people, and how much genuinely free working time is left.
4. Name the days that are already overloaded, before anything gets planned into them.
5. Ask for the week's goals and hold them against the remaining capacity. Negotiate if it does not
add up.
6. Account for travel and office days where the entries reveal them.
7. On approval, `create_event` for the blocks, spread across the week. Leave the weekend alone
unless the user says otherwise.
## Tool access and calendar rules
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.
- **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.
review-my-day6.51 KB
View saved version →
---
name: review-my-day
description: "Close out the day by comparing what was intended against what the calendar actually holds, showing how the time split across calendars, and giving every loose end a concrete slot in the coming days. Use for requests like review my day, how did today go, or wrap up my day."
---
# Review the day
The quiet one, and the one that makes the others compound: it is the only session that leaves
something behind for tomorrow.
## Steps
1. `get_availability` for the day just ending.
2. Sort what you find into three groups: went as intended, moved or was cancelled, turned up
unplanned. If you planned the day earlier in this same conversation, compare against that.
Otherwise ask the user what they had intended, because you cannot know it.
3. For anything that moved, ask why. That is the one thing a calendar never records.
4. Show how the day split across the different calendars, so the user sees how much went into work
and what was left over.
5. Ask what is still open and propose concrete times in the next few days.
After the user approves the plan, use `create_event` for the agreed items.
6. Finish with one sentence about tomorrow that can be handed to the next morning session.
## Tool access and calendar rules
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.
- **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.
schedule-my-goals6.58 KB
View saved version →
---
name: schedule-my-goals
description: "Translate recurring intentions into fixed slots that survive a real week, and check later whether they held. Use for goals like exercising three times a week, regular study time, or any I want to do X regularly request."
---
# Put goals in the calendar
Intentions do not fail for lack of will, they fail because they never appear in the schedule.
## Steps
1. Capture the goals with frequency and duration each: three times a week for 75 minutes, twice a
week for two hours.
2. `get_availability` over the next four weeks and look for the gaps that repeat every week, not
the ones that happen to be free this week.
3. Reality check. If five blocks are meant to fit into weeks that are already full, say so and ask
the user to cut back. A plan that cannot hold is worse than none.
4. Propose fixed slots at the same time each week, each in the calendar it belongs to.
5. On approval, `create_event` per slot.
6. In a later weekly review, check whether the slots held. If the same one keeps getting overrun,
propose a different time rather than repeating it.
## Important
The connected-calendar `create_event` tool creates individual events, not recurring series.
Default to four weeks of separate entries and extend later with the user's approval.
## Tool access and calendar rules
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.
- **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.
timebox-my-day6.82 KB
View saved version →
---
name: timebox-my-day
description: "Turn a task list into a timeboxed day across all the user's calendars, with buffers, travel time and a what-if pass before anything is written. Use for requests like timebox my day, help me schedule these tasks, or I have too much on today."
---
# Timebox the day
The thorough version of a daily plan: every task gets a slot, and the plan is stress-tested before
it is written.
## Steps
1. `list_calendars`, then `get_availability` for the day.
2. Work out the genuinely usable stretches. Anything under twenty minutes is a buffer, not
working time.
3. Ask what needs doing, with a rough duration each. If the total exceeds the free stretches, say
so immediately and make the user prioritise.
4. Put demanding work in the first half of the day, coordination and small items later.
5. Include lunch, buffers, and travel time wherever existing entries carry a location.
6. Run a what-if before committing: if something urgent lands this afternoon, which block dies,
and does the user want it moved earlier or defended.
7. On approval, `create_event` per block.
8. Offer to remove the whole plan again with `delete_event` if the day falls apart. You can do
this because these are events you created.
## Important
Do not promise that a focus block will show up as "busy only" to colleagues. What other people see
depends on provider sharing and any sync's detail level. Creating a focus block does
not change either. The detail level granted to this AI connection does not set colleagues' visibility.
## Tool access and calendar rules
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.
- **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.
