bookings
Booking lifecycle — pending, confirmed, rescheduled, cancelled — plus attendees, references, no-shows, and reminders.
65
77%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./packages/scheduling/docs/skills/bookings/SKILL.mdBookings
Lifecycle
- pending — requires-confirmation event types start here
- confirmed — normal state
- rescheduled — the old booking after a reschedule (the new one is
confirmed;
from_reschedulelinks them) - cancelled — either party cancelled
- rejected — pending was declined
Reschedule vs cancel+rebook
The reschedule-booking action creates a new booking with a link back to
the old via fromReschedule. iCalUID is preserved across the reschedule
chain (RFC 5545), and iCalSequence is bumped.
No-show
mark-no-show sets noShow: true on an attendee. Round-robin calibration
uses this to penalize hosts whose attendees no-show frequently.
Cancel / reschedule tokens
Every booking has a cancelToken and rescheduleToken used in public
magic links sent to attendees. These let them manage the booking without
logging in.
References
External system IDs: Google Calendar event id, Zoom meeting id, Daily.co
room name. Stored in booking_references, used during cancel/reschedule to
propagate changes back to the source system.
ICS
/booking/:uid.ics returns the RFC 5545 calendar file. Used for
confirmation-email attachments and "Add to calendar" buttons.
- Repository
- BuilderIO/agent-native
- Commit
e9a2f0e
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.