Skill instructions
event-from-message2.57 KB
View saved version →
---
name: event-from-message
description: Extract one calendar event from pasted or visible message text and create an editable Event Creator card. Use when the user asks to turn an email, chat, invitation, announcement, or copied notice into one event. Require the source text to be available in the conversation; do not retrieve mail or create multiple events.
---
# Event From Message
Turn one message into one accurate, editable event.
## Inputs
Use message text that is visible in the conversation and any corrections or
preferences the user provides. Accept copied email, chat, invitation,
announcement, or notice text.
## Workflow
1. Identify the single event the user wants.
- If the message contains several distinct events and the user did not choose
one, ask which event to create.
- Ignore signatures, quoted reply history, tracking text, and unrelated
promotional copy.
2. Extract only supported event facts:
- a concise title;
- the start and end, or a start plus an explicit duration;
- an IANA time zone when the source or conversation establishes one;
- an optional description, location, and HTTP(S) event URL.
3. Separate source facts from assumptions.
- Resolve relative dates against the conversation date.
- Ask one concise clarification when ambiguity could change the scheduled
date, time, duration, timing mode, or time zone.
- Do not ask about missing optional details.
- Do not invent a location, URL, end time, or time zone.
4. Choose the timing mode.
- Use timed timing when a time of day is intended.
- Use all-day timing only when the message describes a date-based event with
no intended time of day. Treat its end date as inclusive.
- For a timed event, include an explicit IANA time zone when known. Otherwise
allow `display-event` to use its client time-zone hint; if the tool cannot
resolve one, ask the user for it and retry.
5. Invoke `display-event` once with the normalized event. Include optional
fields only when supported by the source or the user's instructions.
6. Present the resulting editable card. Briefly disclose any non-obvious
interpretation that remained necessary.
## Output
Deliver one editable Event Creator card whose title, timing, time zone, and
optional details match the source.
## Boundaries
- Do not retrieve email, messages, or attachments from another service.
- Do not create multiple events from one invocation.
- Do not add attendees, recurrence, reminders, or calendar-account writes.
- Do not claim the event was added to a calendar. The user exports it from the
widget.
Referenced files: 1 — file references are metadata, not package contents.
flyer-to-calendar-event2.8 KB
View saved version →
---
name: flyer-to-calendar-event
description: Extract one calendar event from a visible flyer, poster, screenshot, or photographed notice and create an editable Event Creator card. Use when the user asks to turn event artwork or an image-based announcement into an event. Require the image to be visible and readable; do not invent text, decode an unreadable QR destination, or create multiple events.
---
# Flyer To Calendar Event
Turn one visible event flyer into one accurate, editable event.
## Inputs
Use the attached or otherwise visible flyer, poster, screenshot, or photographed
notice together with any corrections the user provides.
## Workflow
1. Confirm that the image is available and readable enough to identify an
event. If it is missing or unreadable, ask the user to attach a clearer image
or paste the relevant text.
2. Identify the single event the user wants.
- If the image advertises several sessions, dates, or performances and the
user did not choose one, ask which one to create.
- Distinguish event facts from decorative, sponsor, and promotional text.
3. Extract only supported event facts:
- a concise title;
- start and end information or an explicit duration;
- an IANA time zone when the flyer or conversation establishes one;
- an optional venue or address, description, and clearly readable HTTP(S)
event URL.
4. Check visually ambiguous details before scheduling.
- Ask one concise clarification when a numeric date, missing year, time,
duration, timing mode, or time zone has more than one material
interpretation.
- Do not infer a URL from a QR code whose destination is not visibly decoded.
- Do not invent obscured or cropped text.
5. Choose the timing mode.
- Use timed timing when the flyer specifies or clearly intends a time of day.
- Use all-day timing only for a genuinely date-based event, not merely
because the time is unreadable. Treat its end date as inclusive.
- For a timed event, include an explicit IANA time zone when known. Otherwise
allow `display-event` to use its client time-zone hint; if the tool cannot
resolve one, ask the user for it and retry.
6. Invoke `display-event` once with the normalized event and only supported
optional details.
7. Present the resulting editable card. Briefly disclose any non-obvious
interpretation that remained necessary.
## Output
Deliver one editable Event Creator card based on the readable event facts in
the image.
## Boundaries
- Do not claim to use an OCR, QR-decoding, browsing, or image-retrieval service
that is not available in the conversation.
- Do not create multiple events from one invocation.
- Do not add attendees, recurrence, reminders, or calendar-account writes.
- Do not claim the event was added to a calendar. The user exports it from the
widget.
Referenced files: 1 — file references are metadata, not package contents.
meeting-notes-to-focus-block2.48 KB
View saved version →
---
name: meeting-notes-to-focus-block
description: Turn one action item from visible meeting notes into a scheduled, editable Event Creator focus block. Use when the user asks to reserve time for a follow-up, deliverable, or preparation task identified in notes. Require one concrete action and an exact schedulable slot; do not create tasks, reminders, attendees, recurrence, or multiple blocks.
---
# Meeting Notes To Focus Block
Turn one meeting follow-up into one focused calendar block.
## Inputs
Use meeting notes visible in the conversation plus the user's chosen action,
duration, scheduling window, and time-zone context.
## Workflow
1. Identify the single follow-up to schedule.
- Prefer the action the user names or an action clearly assigned to the user.
- If several plausible actions remain, ask which one to schedule.
- Do not schedule actions owned by someone else without the user's explicit
request.
2. Define a concrete outcome for the block.
- Write a short action-oriented title.
- Distill two to five useful steps, acceptance criteria, or preparation notes
into the description.
- Include a relevant HTTP(S) source or meeting URL only when it is present in
the notes or supplied by the user.
3. Resolve an exact timed schedule.
- Use the start and end the user provides, or calculate the end from an
explicit duration.
- If only a broad window such as "Tuesday afternoon" is given, ask for an
exact start time rather than choosing one silently.
- Include an explicit IANA time zone when known. Otherwise allow
`display-event` to use its client time-zone hint; if the tool cannot resolve
one, ask the user for it and retry.
- Confirm that the end is after the start and that the chosen time is not a
nonexistent DST wall time.
4. Invoke `display-event` once with timed timing and the focused title,
description, and any supported URL or location.
5. Present the resulting editable card. Keep the response centered on the
scheduled block rather than re-summarizing the entire meeting.
## Output
Deliver one editable Event Creator card for a concrete follow-up focus block,
with a concise outcome and actionable description.
## Boundaries
- Do not create a task-system entry or mark an action item complete.
- Do not create multiple focus blocks from one invocation.
- Do not add attendees, recurrence, reminders, or calendar-account writes.
- Do not claim the block was added to a calendar. The user exports it from the
widget.
Referenced files: 1 — file references are metadata, not package contents.
travel-reservation-event3.36 KB
View saved version →
---
name: travel-reservation-event
description: Turn one visible flight, train, bus, ferry, hotel, or other travel reservation into an editable Event Creator card. Use when the user provides itinerary or booking details for one segment or stay. Normalize cross-zone timing into the app's single event time zone; do not retrieve bookings, check live status, expose unnecessary sensitive data, or batch-create an itinerary.
---
# Travel Reservation Event
Turn one supplied travel reservation into one accurate, editable event.
## Inputs
Use reservation or itinerary details visible in the conversation and any
preferences the user provides. Handle one transportation segment or one lodging
stay at a time.
## Workflow
1. Select the single reservation to create.
- If the source contains several segments or stays and the user did not
choose one, ask which one to use.
- Do not silently merge connections, return journeys, or separate bookings.
2. Extract the supported facts.
- Build a concise title that identifies the journey or stay.
- Capture the scheduled start, scheduled end or explicit duration, and the
relevant IANA zones.
- Use the departure, boarding, or check-in place as the event location unless
the user prefers another location.
- Put useful terminal, platform, destination, check-in, or checkout context
in the description.
- Include a valid HTTP(S) booking or information URL only when it is visible
in the source.
3. Protect sensitive information.
- Include a confirmation or booking reference only when the user asks for it
or clearly expects it in the calendar entry.
- Omit payment data, ticket barcodes, loyalty numbers, passport details, and
other unnecessary credentials.
4. Normalize timing into one event time zone.
- For transportation, normally use the departure location's IANA zone.
Interpret the departure in that zone, interpret the arrival in its local
destination zone, then convert the arrival instant into the chosen event
zone for `endLocal`.
- Preserve the original arrival local time and destination zone in the
description when that context helps the traveler.
- For lodging, use the property's IANA zone. Use timed timing when explicit
check-in and checkout times are intended; otherwise use inclusive all-day
dates.
- Resolve date-line crossings, overnight arrivals, and DST before invoking
the tool. Confirm that the end instant is after the start instant.
5. Ask one concise clarification when an ambiguous date, airport or station,
local time, time zone, or missing arrival date could change the event.
Do not ask about missing optional details.
6. Invoke `display-event` once with the normalized event.
7. Present the resulting editable card and briefly note any important zone
conversion used.
## Output
Deliver one editable Event Creator card for one travel segment or lodging stay,
with timing represented accurately in one IANA zone.
## Boundaries
- Do not retrieve reservations from email, airline, hotel, or booking services.
- Do not look up live delays, gates, platforms, cancellations, or check-in
status.
- Do not create several itinerary events in one invocation.
- Do not add attendees, recurrence, reminders, or calendar-account writes.
- Do not claim the reservation was changed or added to a calendar. The user
exports the event from the widget.
Referenced files: 1 — file references are metadata, not package contents.