Clickable prototype in 48h

Scheduling

Calendar scheduling links

Your own scheduling links: booking pages per host and event type, availability with overrides and buffers, Google and Outlook calendar sync, e-mail invites, reminders and self-service reschedule.

Repository
timerise-ai/calendar-scheduling-links
Released
October 15, 2026
Build it with TimeriseBuild it yourself
npx skills add timerise-ai/calendar-scheduling-links
Current release
v0.1.2
Reference docs
18
Non-negotiables
5
License
MIT

The problem

What problem does Calendar scheduling links solve?

A scheduling link looks like the simplest page on the internet: a calendar, some free times, a button. Most teams rent one per seat, every month, and accept that the booking page lives on someone else's domain, sends someone else's e-mails and stops where the vendor's roadmap stops.

The page is the easy part. The hard part is what happens when two people pick the same time, when the host's calendar changed a minute ago, when the clocks go forward on a Sunday night, or when a meeting moves and the reminder still goes out for the old time. Get one of those wrong and a client sits alone on a call.

This skill gives your coding agent the whole core, written by the engineers who build booking systems for a living: availability, booking, calendar sync, invites, reminders, reschedule and cancel links. You own the code, run it on Next.js on Vercel, with Supabase or Firestore, under your own accounts, and extend it with us, with our other skills, or by asking your agent for the next feature.

The module

What does the skill build?

An agent with this skill builds one module for a Next.js App Router app, on your stack. For Calendar scheduling links that module consists of:

  • 1. A public booking page per host and event type
  • 2. Weekly availability with date overrides
  • 3. Buffers and minimum notice
  • 4. Daily limits and group seats
  • 5. Google and Microsoft calendar sync
  • 6. E-mail with an ICS invite
  • 7. Reminders, reschedule and cancel by a private link
  • 8. Signed webhooks
  • 9. An embed widget

Provenance

Where do the rules come from?

This skill was written by the engineer who builds the scheduling core of a booking platform, and audited against the earlier implementation of that core. The templates hold the properties a scheduling module has to hold: a start is booked only if the engine offers it at write time; of any number of simultaneous requests for one slot, one wins; local days survive both DST changes; a reschedule moves the same calendar event and the same invitation; a reminder belongs to the start it was made for; calendar access, manage links and webhooks cannot be forged. 53 unit tests and a store contract, run on local Supabase and the Firestore emulator, state each one, and `references/provenance.md` has the record.

This module is the scheduling core of a booking platform, written down by the engineer who builds it: the slot generation, booking, notification and calendar-sync layers of the earlier implementation, audited end to end and rebuilt for Next.js on Vercel with Supabase or Firestore. The earlier implementation was a long-running API server on a document database. The scope map came from the public feature set of the scheduling-link products the module is an alternative to; the behaviour came from the earlier implementation and from the audit.

The ledger separates what the audit changed, what was kept on purpose, and what has not run in production yet.

  1. Fixed in the templates

    • Slots started late in the evening skipped a whole local date. The engine now iterates local dates with addDays (time-and-slots.md); the spring-forward test walks from 23:45 local.
    • Booking counts seats under a per-host lock, with an exclusion constraint as the backstop (supabase.md); the contract suite sends four concurrent requests and expects one winner.
    • Notifications booking, start and offset (the dedupe key), claimed with a lease.
    • Calendar their calendar to another account. State signed and bound to the signed-in host, plus PKCE (calendar-sync.md).

  2. Designed here, not yet run in production

    • Found by the agent evals Defects in this skill's own 0.1.0 templates, found when an agent patched them during an eval run, reproduced against the template, and fixed in 0.1.1. Apps built from 0.1.0 should copy the fixed files.
Read the full record in provenance.md ›

Non-negotiables

What are the 5 rules the module never breaks?

Every module built from this skill holds these, whoever builds it. The same list is in the skill's README and SKILL.md, so the agent reads it before it writes a line.

  1. The write recomputes the slot with the engine that listed it.

    A start is booked only if computeSlots offers it at write time. The booking suite books what the page listed and refuses an off-grid start, a start inside the notice and one outside hours.

  2. Every booking write is atomic per host.

    Seats, the daily limit and overlap are checked under one lock per host, with the overlap constraint as the backstop. The store contract sends four simultaneous requests for one slot to each store and expects one winner.

  3. Side effects are jobs, written with the change and run after it.

    No e-mail, calendar call or webhook inside the transaction; every job idempotent and re-checking the booking. The booking suite runs the queue twice and expects one send, retries a failing mailer, and plants a stale reminder that must not be sent.

  4. Instants in storage, zones only at the edges.

    Store UTC instants; convert with an explicit IANA zone, iterate local dates, never add 24 hours. The time and engine suites cover both DST changes, a 5:45 offset and a late-evening walk across a spring-forward night.

  5. Secrets stay sealed and links stay unforgeable.

    Manage tokens stored as hashes, OAuth tokens and webhook secrets encrypted, OAuth state and channel tokens signed, cron auth failing closed. The edges suite checks each.

Fit

When should you use it, and when not?

Use it for

  • Public booking pages for one or many hosts, each with their own event types and availability.
  • One-on-one meetings and group sessions with seats.
  • Avoiding the host's Google or Microsoft calendar, and writing bookings into it.
  • Auditing or rebuilding a scheduling module: provenance.md has the audit ledger and the fix order.

Not for

  • Payment for a booking, deposits, no-show holds, ticketed events with seats on one dateInsteadbookable-events
  • A marketplace that pays providersInsteadstripe-connect-subscriptions
  • A walk-up booking terminalInsteadbooking-kiosk
  • Host notifications in SlackInsteadslack-ai-bot
  • Knowing who opened a booking linkInsteadvisit-logger
  • Invoices for paid sessionsInsteadinvoicing
  • Round robin, collective events, routing formsInsteadextensions.md, no templates yet

Build it yourself

How do I install it?

One command. The skills.sh CLI installs the skill into every skills-compatible agent it finds.

$ npx skills add timerise-ai/calendar-scheduling-links

Claude Code

Invoke with /calendar-scheduling-links

Codex CLI

Invoke with $calendar-scheduling-links

Gemini CLI

Invoke with /skills

Name the agents instead with -a, for example npx skills add timerise-ai/calendar-scheduling-links -a claude-code -a codex. Or clone the repository into your agent's skills folder. Nothing in it is agent-specific.

What is inside the repository (21 entries)
  • SKILL.mdEntry point: trigger, architecture, adaptation contract, critical facts, hard rules, quick start, reference directory
  • references/data-model.mdVocabulary, types, what each field is for, records, the rename table
  • references/time-and-slots.mdTime helpers on Intl, the slot engine and the order of its rules
  • references/booking-flow.mdThe store seam, the booking service, errors, host-side validation
  • references/supabase.mdMigration with RLS, grants, the exclusion constraint and the atomic SQL functions
  • references/supabase-stores.mdsupabaseStore and supabaseCalendarStore
  • references/firestore.mdThe Firestore store, its lock document, indexes and rules
  • references/jobs-and-notifications.mdThe jobs table and runner, e-mail, ICS
  • references/webhooks.mdSigned webhooks, the payload and the private-address guard
  • references/calendar-sync.mdThe provider contract, OAuth with signed state and PKCE, sync, watches, the writer
  • references/calendar-providers.mdGoogle Calendar and Microsoft Graph, with the vendor facts they rely on
  • references/api-routes.mdRuntime wiring, the auth seam, tokens and sealing, every route
  • references/booking-page-ui.mdPublic page, widget, manage page, embed script, dashboard rules
  • references/operations.mdEnvironment, Vercel Cron or pg_cron, Google and Microsoft setup, deploy, monitoring
  • references/extensions.mdRound robin, collective, routing, payments and more, with prompts
  • references/testing.mdVitest setup, fixtures, the time and engine suites, running against real stores
  • references/testing-flows.mdThe booking, edges and store contract suites
  • references/adaptation.mdHost prerequisites, seam contract, order of work, the non-negotiables
  • references/provenance.mdThe audit ledger: fixed, kept deliberately, designed here
  • evals/prompts.md with what an operator types, and one file per agent eval run
  • .github/workflows/agent-eval.ymlRuns the agent evals on every published release

Recent releases

  1. v0.1.2October 15, 2026

    Fix release, from scoring the prompt-1 agent eval runs against 0.1.1. Apps built from 0.1.0 or 0.1.1 should copy booking-service.ts, booking-widget.tsx and the new manage slots route.

  2. v0.1.1October 15, 2026

    Fix release, from scoring the prompt-1 agent eval runs against 0.1.0. Apps built from 0.1.0 should copy runner.ts, calendar/writer.ts, calendar/sync.ts, booking-widget.tsx and cancel-form.tsx.

  3. v0.1.0October 15, 2026

    First release: self-hosted scheduling links for Next.js App Router on Vercel, with Supabase or Firestore.

SKILL.md ›README.md ›CHANGELOG.md ›

After installing

What do I tell my agent?

Say what you need in your own words; the skill supplies the how. These are starting points, and the ones we tested say how it went.

  1. Add Calendly-style booking links to this Next.js app on Supabase: hosts set their weekly availability and event types, visitors book a free time on a public page, both get an e-mail with a calendar invite, and the visitor can reschedule or cancel from a link in that e-mail.

    SupabaseGemini CLIBuilt, checks passCodex CLIBuilt, checks passClaude CodeBuilt, checks pass

  2. Connect our booking pages to the host's Google Calendar and Outlook: hide times when they are busy and put every booking into their calendar.

    Supabase

  3. Audit our scheduling module: people get double-booked, reminders arrive for meetings that were moved, and around the clock change some days have no slots.

Tested

How does it do in each agent?

We install the skill into an empty Next.js app, give the agent one of the prompts above and no further help, then type-check, build and run the tests it left behind. Nothing is fixed by hand before the checks, and a failing run is published like a passing one. The procedure and every result are public, and the first prompt runs again before each release.

  • Gemini CLI0.64.0

    gemini-3.8-flash

    Built, checks pass
    Add Calendly-style booking links to this Next.js app on Supabase: hosts set their weekly availability and event types, visitors book a free time on a public page, both get an e-mail with a calendar invite, and the visitor can reschedule or cancel from a link in that e-mail.
    Typecheck: passBuild: passTests: pass
    Time
    19 min
    Changed
    64 files, +6,368 lines
    Stack
    Supabase
    Skill
    v0.1.2
    Run
    Oct 15, 2026

    Result file ›Agent log ›

    What we saw

    Rubric 8/8, scored from the JSON summary, with doubt on item 2, which a summary cannot settle: "fallback values are provided during Next.js static page generation" may describe its own dashboard or a template. The suite runs as shipped (58 passed) from vitest.config.mts, the reschedule listing route is in place, and the handover names every variable, the migration, the cron with pg_cron, the sender and both OAuth apps with their redirect URIs.

  • Codex CLIcodex-cli 0.162.1

    gpt-6.1-sol

    Built, checks pass
    Add Calendly-style booking links to this Next.js app on Supabase: hosts set their weekly availability and event types, visitors book a free time on a public page, both get an e-mail with a calendar invite, and the visitor can reschedule or cancel from a link in that e-mail.
    Typecheck: passBuild: passTests: pass
    Time
    3 min
    Changed
    68 files, +6,190 lines
    Stack
    Supabase
    Skill
    v0.1.2
    Run
    Oct 15, 2026

    Result file ›Agent log ›

    What we saw

    Rubric 8/8, scored from the transcript. First clean run: every template written from its block and not edited after, host.ts the Supabase Auth version (a separate lib/auth/server.ts serves its own dashboard), the suite as shipped (58 passed, 5 skipped), .env.example with all fifteen variables empty and a !.env.example exception, and a final message naming every variable, the migration, the sender, the cron and both OAuth callback URIs. Not scored: it wrote the five-minute cron to vercel.json rather than vercel.ts.

  • Claude Code2.1.300

    claude-opus-5-5

    Built, checks pass
    Add Calendly-style booking links to this Next.js app on Supabase: hosts set their weekly availability and event types, visitors book a free time on a public page, both get an e-mail with a calendar invite, and the visitor can reschedule or cancel from a link in that e-mail.
    Typecheck: passBuild: passTests: pass
    Time
    5 min
    Changed
    81 files, +7,258 lines
    Stack
    Supabase
    Skill
    v0.1.2
    Run
    Oct 15, 2026

    Result file ›Agent log ›

    What we saw

    Rubric 8/8, scored from the JSON summary. The suite runs as shipped (58 passed, 5 skipped), the templates are copied unchanged by the summary's own account, with the dashboard, sign-in, proxy.ts and a /<handle> page written beside them, and the final message names every variable, then the migration, the cron with pg_cron on Hobby, the SendGrid sender and both OAuth apps with their redirect URIs.

Build it with Timerise

How long does it take, and what does it cost?

We quote this module per project. The price depends on what it has to connect to. The path to a number is short and free:

  1. Step 1

    Brief

    Tell us what the module must connect to. Takes minutes, in a chat.

  2. Step 2

    Prototype in 48 hours

    A clickable prototype of your system and a quote, at no cost.

  3. Step 3

    Build and handoff

    One project price. Source code, documentation and IP are yours.

Two ways to get Calendar scheduling links

Build it yourself

Install the skill. Your own agent builds the module.

  • MIT licensed, no strings
  • Runs in Claude Code, Codex CLI and Gemini CLI
  • The same rules our engineers build by
$ npx skills add timerise-ai/calendar-scheduling-links
Install the skill

Build it with Timerise

Send a brief. We build Calendar scheduling links into a system you own.

  • Clickable prototype and a quote within 48 hours, free
  • One project price, no subscription, no commission
  • Source code, documentation and IP handed over
3 years of support included.
Start the brief

Generated from the skill's own files at commit 5f0e85f. Every rule above links to where the repository says it. All skills