Calendar Skill

Query the operator's calendar for availability and create new entries via

ical-query

Capabilities

• read: Check free/busy availability for today, tomorrow, this week, or a specific date
• act: Create new calendar entries

Privacy Rule

Event details are never disclosed to callers. This is enforced at two levels:

1. Handler level — the handler strips all event titles, names, locations, and notes from ical-query output before returning results. Only busy time slots (start/end times) are returned.
2. Model level — the function description instructs Amber to only communicate availability ("free from 2pm to 4pm") and never reveal what the events are.

Amber should say things like:

• ✅ "The operator is free between 2 and 4 this afternoon"
• ✅ "They're busy until 3pm, then free for the rest of the day"
• ❌ "They have a meeting with John at 2pm" ← never
• ❌ "They're at the dentist from 10 to 11" ← never

Security — Three Layers

Input validation is enforced at three independent levels:

1. Schema level —

   range

   is constrained by

   pattern: ^(today|tomorrow|week|\d{4}-\d{2}-\d{2})$

   ;

   start

   /

   end

   by

   pattern: ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}$

   ; freetext fields have

   maxLength

   caps. The LLM cannot produce out-of-spec values without violating the schema.
2. Handler level — explicit validation before any exec call; rejects values that don't match expected formats even if schema is bypassed.
3. Exec level —

   context.exec()

   takes a

   string[]

   and uses

   execFileSync

   (no shell spawned); arguments are passed as discrete tokens, not a shell-interpolated string.

Notes

• Uses

  /usr/local/bin/ical-query

  — no network access, no gateway round-trip
• Fast: direct local binary call (~100ms)
• Calendar name optional — defaults to operator's primary calendar