/process-meetings

name: process-meetings
description: "Turn synced meetings into updated person pages, extracted tasks and organized notes. Use when the user says 'process my meetings', 'catch up my notes', or after Granola/Otter syncs. Also use proactively when unprocessed meetings exist. Not for prepping an upcoming meeting; use `meeting-prep`."
model_hint: balanced
hooks:
  PostToolUse:
    - matcher: Write
      type: command
      command: "node .claude/hooks/post-meeting-person-update.cjs"

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-and-processing 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 `.claude/skills/process-meetings/AGENT_INSTRUCTIONS.md`. 2. Substitute its placeholders (`{{ARGS}}`, the arguments passed to this skill). 3. Call the Agent tool with `subagent_type: "general-purpose"`, that prompt, and a short description. 4. Display its summary report.

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 meetings: 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 this skill's hook for the subagent's writes.** The

PostToolUse hook `post-meeting-person-update.cjs` is declared in this SKILL.md's frontmatter, so it belongs to this skill's run and must not be assumed to cover a subagent's writes. `AGENT_INSTRUCTIONS.md` therefore has the subagent update person pages itself. Do not remove that instruction believing the hook covers it. It is also safe if the hook does run for those writes: both write the same "Recent Interactions" line format, and both skip a person page that already references the meeting, so the entry cannot be added twice.

• **Always fall back.** If the subagent fails, times out, or returns nothing

usable, say so plainly and run the processing inline from the same `AGENT_INSTRUCTIONS.md`. A missing subagent must never mean a missing result.

**Stays inline:** the background-sync status check when it needs setup guidance (`--setup`), the Granola pre-flight message when no API key is connected, confirming each detected soft commitment before any task is created, resolving ambiguous person matches and entity suggestions, and presenting the final summary report.

**Check the report for unstamped meetings.** The subagent leaves a meeting without its `tasks-extracted` marker whenever a task failed to create or stamp, and reports the exact failing line. Surface those lines rather than burying them: an unstamped meeting is the safe state, but it stays flagged as waiting until someone resolves it.

**The report is a claim, not evidence — check it before repeating it.** This subagent writes to the vault, and its summary states counts the user will act on. Before displaying it, verify the claims cheaply against the vault:

• Every task it says it created: confirm the ID appears in `03-Tasks/Tasks.md`

(`list_tasks`, or read the file).

• Every meeting it says it stamped: confirm the `tasks-extracted` marker is

actually in that note.

• Every person or company page it says it created: confirm the file exists.

If a claim does not hold, say so plainly in the summary you present and treat that meeting as unprocessed. Never pass an unverified count to the user as fact, and never repeat "processing complete" on the strength of the report alone.

Process Meetings

Process meetings that have been synced from Granola by the background automation. Updates person pages, extracts tasks, and organizes meeting notes.

Background Execution

This skill supports background execution. When invoked: 1. Acknowledge: "Processing [N] meetings in the background. I'll let you know when done." 2. Process all meetings 3. On completion, provide summary: "[N] meetings processed. [X] person pages updated. [Y] action items created."

How It Works

Meetings are synced automatically every 30 minutes by a background process. This command reads those synced files and:

• Creates/updates person and company pages
• Extracts action items to 03-Tasks/Tasks.md
• Links everything together

**No terminal commands are shown** - the heavy lifting happens in the background.

Arguments

• No arguments: Process all unprocessed meetings from the last 7 days
• `today`: Only process today's meetings
• `"search term"`: Find meetings by title/attendee
• `--people-only`: Only update person/company pages (skip tasks)
• `--no-todos`: Create notes but don't extract tasks
• `--setup`: Install/check background automation

Pre-flight: Local Source Check

Read `meeting_sources` in `System/user-profile.yaml` before assuming a recorder. The configured `primary` is provenance, not permission or tool