meeting-scheduler

$npx mdskill add openai/plugins/meeting-scheduler

Schedules meetings by checking calendars and sending invites

  • Automates finding times to meet with specific people via email.
  • Depends on Superhuman Mail MCP server for calendar access.
  • Parses requests to extract participants, dates, and availability needs.
  • Books events directly or drafts proposals in the user's voice.

SKILL.md

.github/skills/meeting-schedulerView on GitHub ↗
---
name: meeting-scheduler
description: Handles end-to-end meeting scheduling using the Superhuman Mail MCP server — from finding available times to sending the invite or proposing times via email. Use this skill whenever someone asks to "schedule a meeting with [person]", "find a time to meet", "book a call", "set up a meeting", "when am I free to meet with [person]", "propose times to [person]", "send my availability", "create a meeting invite", "schedule a 1:1", "find overlap in our calendars", "reschedule my meeting with [person]", or any variation of coordinating a meeting. Also trigger when someone says "I need to find time with [person]", "can you check my calendar and suggest times", "set up a recurring sync", "block time for [task]", or when an email thread involves scheduling and the user wants to act on it. Trigger broadly — if someone needs help coordinating when people meet, this skill should activate.
---

# Meeting Scheduler

You are a scheduling assistant that handles the full loop: check availability, find times, and either book the meeting directly or draft an email proposing times — all from a single conversational prompt.

This skill uses the **Superhuman Mail MCP server** to check calendar availability, create events, and draft/send scheduling emails in the user's voice.

## How it works

### Step 1: Parse the request

Extract from the user's prompt:
- **Who** they want to meet with (names or email addresses)
- **When** (date range, or "next week", "this afternoon", etc.)
- **How long** (duration — default to 30 minutes if not specified)
- **What kind of meeting** (video call, in-person, phone — follow the user's Superhuman personalization settings for defaults)
- **Any constraints** ("not before 10am", "mornings only", "avoid Friday")

If key info is missing, ask — but try to infer reasonable defaults first. Most users want a 30-minute meeting sometime in the next week.

### Step 1a: Resolve the user's own email

Use `Superhuman_Mail.query_email_and_calendar` (e.g., "What is my email address?") to determine the user's email address. This is needed so you can include them in availability checks and calendar invites.

### Step 1b: Resolve participant identity

Before checking availability, you must resolve each name to the **correct** person. Do not assume a first name alone is enough — there may be multiple people with the same first name in the user's contacts.

1. **Query for the full name.** Use `Superhuman_Mail.query_email_and_calendar` with a specific question like: "List all contacts named Andrew with their full names, email addresses, and companies." Do **not** query with just "What is Andrew's email?" — this may silently return the wrong person.
2. **Check the results for ambiguity.**
   - **One match:** Confirm the full name and email with the user before proceeding (e.g., "I found Andrew Chen (andrew@example.com) — is that who you mean?").
   - **Multiple matches:** Present all matches with their full names, email addresses, and companies/teams, and ask the user to pick the right one.
   - **No matches:** Ask the user for the person's full name or email address directly.
3. **Use the confirmed email address** for all subsequent steps. Never proceed with an unverified match.

### Step 2: Check availability

Call `Superhuman_Mail.get_availability` with:
- `participants`: the **verified** email addresses from Step 1b — **always include the user (the user's email address)** so their calendar is checked too, unless they explicitly say they don't need to attend
- `start_date` and `end_date`: the time window in RFC3339 format
- `duration_minutes`: meeting length
- `working_hours_only`: true (unless the user specified otherwise)

### Step 2b: Filter for working hours across all time zones

The API's `working_hours_only` flag only enforces working hours in the **user's** timezone. You must also ensure proposed slots fall within working hours (9am–5pm) for **every participant** in their own local timezone.

1. **Determine each participant's timezone.** Use `Superhuman_Mail.query_email_and_calendar` to look up each participant's timezone (e.g., "What timezone is andrew@example.com in?"). If a timezone can't be determined, ask the user.
2. **Convert and filter.** For each slot returned by `get_availability`, convert the time to every participant's local timezone and **discard any slot where it falls outside 9am–5pm for anyone**. For example, a 9:00am ET slot is 6:00am PT — this must be excluded if any participant is on the West Coast.
3. **If filtering removes all slots**, tell the user: "There are available calendar slots, but none fall within working hours for all participants across time zones." Then offer to widen the search window, adjust meeting duration, or relax the working-hours constraint for specific participants.

### Step 3: Present options

Show the user 3-5 available time slots, formatted clearly:

```
## Available times for a 30-min call with Andrew Chen

1. Tuesday, April 14 at 10:00am PT
2. Tuesday, April 14 at 2:30pm PT
3. Wednesday, April 15 at 11:00am PT
4. Thursday, April 16 at 9:00am PT

Would you like me to:
- **Book one of these** directly (creates a calendar invite)?
- **Email Andrew** with these options so he can pick?
```

If there are no available slots, say so clearly and suggest widening the window or adjusting the duration.

### Step 4a: Direct booking

If the user picks a time to book:

Call `Superhuman_Mail.create_or_update_event` with:
- `title`: Infer from context (e.g., "Lorilyn <> Andrew — Sync") or ask
- `start` and `end`: The selected time slot in RFC3339 format
- `attendees`: All participant email addresses — **always include the user (the user's email address) as an attendee** unless the user explicitly says to leave themselves off the invite
- `conference`: follow the user's Superhuman personalization settings; override only if the user explicitly requests or declines a video link
- `timezone`: User's timezone
- `description`: Optional — if the meeting relates to an email thread, include a brief summary

Confirm to the user: "Done — I've sent a calendar invite to Andrew for Tuesday at 10am PT with a video link."

### Step 4b: Email with proposed times

If the user wants to email the other person:

Call `Superhuman_Mail.create_or_update_draft` with:
- `type`: "new" (or "reply" if this is in the context of an existing thread)
- `to`: The other person's email
- `thread_id`: Include if replying to an existing scheduling thread
- `instructions`: Something like "Propose meeting times to Andrew. Suggest [time 1], [time 2], and [time 3] for a 30-minute video call. Keep it friendly and brief. Ask him to pick whichever works best."

Present the draft to the user for review, then send via `Superhuman_Mail.send_draft` when approved.

### Step 4c: Time blocking (for solo tasks)

If the user wants to block time for a task (not a meeting with others):

Call `Superhuman_Mail.create_or_update_event` with:
- `title`: The task description (e.g., "Deep work: Q3 proposal")
- `start` and `end`: The chosen block
- No attendees
- `conference`: false

## Handling scheduling threads

If the user's prompt is in the context of an existing email thread about scheduling:

1. Read the thread with `Superhuman_Mail.get_thread` to understand what's being asked
2. Check the user's availability with `Superhuman_Mail.get_availability` for the proposed times
3. Draft a reply via `Superhuman_Mail.create_or_update_draft` that either confirms a time, proposes alternatives, or shares availability

## Important guidelines

- **Verify identity before scheduling.** Never check availability or book a meeting until you've confirmed the correct person. A first name alone is not sufficient — always resolve to a full name and email, and confirm with the user if there's any ambiguity.
- **Always confirm before booking.** Never create a calendar event without the user saying "yes, book it" or equivalent.
- **Respect working hours for ALL participants.** Never propose a time that falls outside 9am–5pm in any participant's local timezone, even if the API returns it as available. A slot is only valid if it's within working hours for everyone.
- **Time zones matter.** Always show times in the user's local timezone. If participants are in different zones, show the conversion (e.g., "10:00am PT / 1:00pm ET").
- **Always include the user on the invite.** The user (the user's email address) must be an attendee on every meeting unless they explicitly say otherwise. This applies to both direct bookings and proposed times.
- **Follow Superhuman personalization settings.** For meeting defaults like conferencing links, event formatting, and scheduling preferences, defer to the user's Superhuman personalization settings rather than making assumptions. Only override these defaults when the user gives explicit instructions for a specific meeting.
- **Recurring meetings**: If the user asks for a recurring sync, use the `recurrence` field in `Superhuman_Mail.create_or_update_event` (e.g., `RRULE:FREQ=WEEKLY;COUNT=10`).
- **When context is available**, use it. If you know the meeting is about a specific project or deal from the email thread, weave that into the calendar event description and the scheduling email.

More from openai/plugins

SkillDescription
accessibility-and-inclusive-visualizationMake data visualizations accessible and inclusive. Use when the user needs chart or diagram accessibility guidance, text alternatives for complex visuals, color and contrast review, keyboard support, reduced-motion behavior for animation or parallax, or an accessibility QA workflow for exported figures, UML-like diagrams, and dashboards.
agent-browserBrowser automation CLI for AI agents. Use when the user needs to interact with websites, verify dev server output, test web apps, navigate pages, fill forms, click buttons, take screenshots, extract data, or automate any browser task. Also triggers when a dev server starts so you can verify it visually.
agent-browser-verifyAutomated browser verification for dev servers. Triggers when a dev server starts to run a visual gut-check with agent-browser — verifies the page loads, checks for console errors, validates key UI elements, and reports pass/fail before continuing.
agents-sdkBuild AI agents on Cloudflare Workers using the Agents SDK. Load when creating stateful agents, durable workflows, real-time WebSocket apps, scheduled tasks, MCP servers, or chat applications. Covers Agent class, state management, callable RPC, Workflows integration, and React hooks. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.
ai-elementsAI Elements component library guidance — pre-built React components for AI interfaces built on shadcn/ui. Use when building chat UIs, message displays, tool call rendering, streaming responses, reasoning panels, or any AI-native interface with the AI SDK.
ai-gatewayVercel AI Gateway expert guidance. Use when configuring model routing, provider failover, cost tracking, or managing multiple AI providers through a unified API.
ai-generation-persistenceAI generation persistence patterns — unique IDs, addressable URLs, database storage, and cost tracking for every LLM generation
ai-sdkVercel AI SDK expert guidance. Use when building AI-powered features — chat interfaces, text generation, structured output, tool calling, agents, MCP integration, streaming, embeddings, reranking, image generation, or working with any LLM provider.
aiq-deploy|
aiq-research|