Meeting Prep

<!-- Generated from `.claude/skills/meeting-prep/SKILL.md` by `scripts/generate-agents-skills.py`. Do not edit. -->

Execution mode

Run inline in the current conversation by default, so this work can see what the user has already discussed, decided, or settled this session. Do not fork merely because this skill was selected. Only run in the background when the user explicitly asks for a background run or the host has already obtained a specific background-work approval for this run.

Delegated gathering (large-vault scaling)

This skill stays inline as described above: it keeps session awareness, it asks the user the questions, and it owns every interactive step. What it does NOT do inline is the bulk read-gathering, which on a mature vault (hundreds of notes, thousands of indexed messages, a live calendar and multiple integrations) can be large enough to exhaust the main conversation before the useful work starts.

So the gathering phase is delegated to one general-purpose subagent via the Agent tool, using the self-contained prompt in this skill's AGENT_INSTRUCTIONS.md:

1. Read .agents/skills/meeting-prep/AGENT_INSTRUCTIONS.md.
2. Substitute its placeholders ({{TARGET_DATE}}, {{MEETING_TITLE}}, {{ATTENDEE_RECORDS}}). {{ATTENDEE_RECORDS}} is the filtered JSON array from the selected invite, preserving name, person_page, email, status, type, and is_current_user for each attendee. For attendees the user supplied manually, use the same fields with unknown values set to null, type set to Person, and is_current_user set to false.
3. Call the Agent tool with subagent_type: "general-purpose", that prompt, and a short description.
4. Present its findings as the prep brief, in the Output Format below.

Spot-check before presenting: the brief names person pages, projects and past meetings. Confirm a sample of those files actually exist before repeating their content to the user, and drop anything you cannot stand behind. A subagent's report is a claim, not evidence.

The subagent inherits MCP connections, runs in its own context, and that context is freed when it completes, so only its findings reach this conversation.

Use AGENT_INSTRUCTIONS.md verbatim. Read the file and pass its content as the subagent prompt, substituting only the placeholders. Do NOT hand-write a replacement brief from what you already know about the meeting: that is how steps get silently dropped, and the omission looks complete because nothing errors. If context from this conversation is worth adding, APPEND it to the file's content; never substitute for it.

Two caveats that are load-bearing:

• Do not count on hooks for the subagent's writes. The hooks declared in this skill's own frontmatter belong to this skill's run, not the subagent's, and whether the repository-wide hooks in the host's lifecycle settings reach a subagent's tool calls is not something a skill should assume either way. Nothing in this skill's gathering depends on a hook; the subagent's writes must stand on their own.
• Always fall back. If the subagent fails, times out, or returns nothing usable, say so plainly and run the gathering inline from the same AGENT_INSTRUCTIONS.md. A missing subagent must never mean a missing result.

Stays inline: confirming which meeting is meant, and presenting the brief.

Prepare for an upcoming meeting by gathering context on attendees and related topics.

Tone Calibration

Before executing this command, read System/user-profile.yaml → communication section and adapt:

Career Level Adaptations:

• Junior: Provide more context about attendees, suggest preparation tips
• Mid: Balance context with action, suggest talking points
• Senior/Leadership: Strategic framing, influence opportunities, key decisions
• C-Suite: High-level strategic context, organizational implications, key stakeholders

Directness:

• Very direct: Bullet points, key facts only
• Balanced: Context + talking points (default)
• Supportive: Detailed prep, conversation strategies

Detail Level:

• Concise: Names, roles, top 3 talking points
• Balanced: Standard prep format
• Comprehensive: Full context, relationship dynamics, strategic considerations

See CLAUDE.md → "Communication Adaptation" for full guidelines.

Arguments

Optional: $MEETING, $ATTENDEES

If either value is missing, try the calendar before prompting. Ask for the meeting topic or attendee list only when the calendar status or the returned events cannot identify the meeting safely.

Examples:

• /meeting-prep "Q1 Planning" "Sarah Chen, Mike Rodriguez"
• /meeting-prep (then prompt for details)

What This Does

1. Reads the matching calendar invite and keeps its resolved attendee records
2. Looks up only attendees whose invite record has no person_page
3. Surfaces recent interactions and open action items
4. Checks for related projects
5. Suggests talking points based on context

Process

Step 0: Refresh the meeting record

Before reading anything, run /process-meetings so the brief is built on the freshest locally available record. It turns captures already sitting unprocessed in the local meeting folder into notes and updates the person and company pages from them. It does not reach out to an external meeting source, so anything not yet synced there stays out of reach either way; what this removes is the gap between a capture arriving locally and it being readable here.

• If no new meetings are found, continue silently
• If meetings are processed, use the extracted context in the brief below
• Do NOT ask for a skill rating after this sub-step, save that for the end of the prep

Why this skill in particular needs it. /meeting-prep is normally run minutes before a call, which is exactly when the most recent conversation with these attendees is most likely to have been captured but not yet processed. Step 3 below reads 00-Inbox/Meetings/, and a brief built from an unprocessed folder does not look incomplete: it looks like there was nothing to report. Missing context and no context are indistinguishable in the output, which is why the refresh belongs before the read rather than being left to chance.

Step 0.5: Gather Context (if needed)

If $MEETING or $ATTENDEES are not provided, try the calendar before asking. The user booked the meeting; the invite already holds the title and the attendee list, and asking them to retype it is both friction and a source of duplicate person pages from misspelt names.

When the calendar integration is available, search every calendar visible to Apple Calendar by default:

mcp__calendar-mcp__calendar_get_events_with_attendees(calendar_name="all", start_date="YYYY-MM-DD", end_date="YYYY-MM-DD")

calendar_name="all" means all calendars currently visible to the local Apple Calendar integration. It cannot see a calendar account that is not synced into Apple Calendar, and on hosts that do not support the all selector you must say which single calendar was searched. Never describe a no-match from one calendar as proof that the meeting is absent from every calendar.

The end date is exclusive. For a single day, pass the following day as end_date. Passing the same date twice returns zero events with no error, which is indistinguishable from an empty calendar.

Match the user's phrasing to an event:

• A time ("prep me for the 2pm", "tomorrow's 1:30"): match on start time, usually unambiguous on its own.
• A person or topic ("prep me for the Acme call"): match on title, or on an attendee name within the event's attendees list.
• Nothing specified: list today's and tomorrow's events and ask which one is meant.

Each attendee carries name, email, status, type, is_organizer, is_current_user, plus has_person_page and (when resolved) person_page, so the vault lookup in Step 1 is already done for anyone who has a page.

Before delegating gathering, build {{ATTENDEE_RECORDS}} from the selected event. Preserve name, person_page (or null), email, status, type, and is_current_user; do not reduce the records to display names. Filter out:

• the user (is_current_user: true)
• Room, Resource, and Group attendee types
• invitees whose status is Declined or Delegated

Keep Person attendees who are Accepted or Tentative. A Pending or Unknown person may still attend: keep them, but do not describe their attendance as confirmed. Never describe the organiser as someone who has not accepted. Calendar APIs often leave the organiser as Pending, Unknown, or needsAction; treat is_organizer: true, Google organizer: true / matching organizer.email, and the user themselves when they organised the meeting (is_current_user / self plus organiser) as accepted. If an attendee has an unknown type, keep them only when they have a usable name or email and flag that uncertainty in the brief.

Ask when the calendar cannot answer. The calendar is the preferred source, not a required one, and this skill must still work without it. Inspect the complete calendar response before reading events or count, and follow CLAUDE.md's Calendar response confidence contract at this inline call site:

• Only success: true is a healthy read. A healthy count: 0 means the searched range is empty only when the response has no warning; preserve a warning and ask rather than claiming there are no meetings.
• feature_status: off is healthy optional absence. Ask for the meeting and attendees with no error tone, setup advice, or nag.
• feature_status: not_installed surfaces the returned user_message and fix once in a calm setup tone, then asks for the meeting and attendees.
• feature_status: broken surfaces the returned user_message exactly, including its permission or other fix guidance, then asks so prep can continue. Never recast it as “not connected” or “no meetings.”
• feature_status: unknown, or an unstructured tool error, means the calendar could not be checked. Say that plainly and ask rather than guessing.
• No Calendar tool response (for example, on a non-macOS machine) is optional absence. Ask for the meeting and attendees without reporting a fault.

Every non-healthy branch is unavailable evidence, not an empty calendar. Never substitute an empty event list for a missing or failed response.

• No matching event in the range returned: ask which meeting is meant rather than guessing.
• Two events match a stated time: that is a double-booking. Name both and let the user choose; it is worth telling them about in itself.

Never treat an empty result as proof of an empty calendar. A tool that is absent, a permission that was refused, and a query built with the wrong range all return nothing, and none of them mean "no meetings". If you cannot tell which it was, say so and ask.

When asking, accept any natural format: "Sarah Chen, Mike Rodriguez", "Sarah, Mike", or a plain list.