vault-meeting

name	vault-meeting
description	Process a meeting transcript — extract decisions, action items, and key discussion points into structured vault entries
allowed-tools	["vault_create_entry","vault_update_entry","vault_search","vault_link","vault_kanban","vault_dashboard","vault_audit","decision_log","fetch_content","context_offload","ask_user","team_spawn"]

Process a meeting transcript and extract structured information into the knowledge base.

Team Mode (Large Transcripts)

If the transcript is very long (60+ minutes of conversation, or the user requests team processing), spawn a team to parallelize the work:

team_spawn(
  team_name: "meeting-processing",
  purpose: "Process a long meeting transcript into structured vault entries",
  roles: [
    %{name: "meeting-lead", role: "lead"},
    %{name: "vault-researcher", role: "researcher"},
    %{name: "vault-writer", role: "coder"},
    %{name: "vault-reviewer", role: "reviewer"}
  ]
)

Team roles:

• meeting-lead: Orchestrates extraction, manages redaction judgment, coordinates. Reads the transcript, identifies decisions/action items/topics, delegates creation to the writer.
• vault-researcher: Queries vault for related context — prior decisions on discussed topics, open tasks for mentioned projects, recent checkins from attendees. Provides context to the lead and writer.
• vault-writer: Creates the meeting note, decision records, atomic notes, and kanban items with proper formatting and linking. Works from the lead's extraction.
• vault-reviewer: Validates output quality — checks for temporal language in notes, verifies link targets exist, ensures frontmatter is complete. Runs vault_audit on created entries.

The researcher and writer can work in parallel on different aspects. For shorter meetings (under 60 minutes), skip team mode and process single-agent.

---

Step 0: Get the Transcript

Determine where the transcript is:

• Pasted directly: Use the text from the user's message
• Google Drive link or file ID: fetch_content(source: "google_drive", identifier: "{file_id}")
• URL: fetch_content(source: "url", identifier: "{url}")
• Local file reference: Use vault_read or file_read as appropriate

If the user says something like "process the meeting from Drive" without a specific file, use ask_user to get the file ID or link.

Step 1: Check for Prep

Search for a prep file matching the meeting date: vault_search(query: "prep", entry_type: "meeting", tags: ["prep"])

If prep exists:

• Read it to understand the planned agenda
• Track which topics get covered during processing
• You will mark covered topics and report coverage at the end

Step 2: Handle Long Transcripts

If the transcript is very long (appears to be 20+ minutes of conversation), offload it to a context keeper: context_offload(topic: "meeting-transcript-{date}", content: ...)

This preserves the full transcript at high fidelity without consuming your context window.

Step 3: Analyze the Transcript

Read through and identify:

Attendees — who spoke in the meeting

Decisions — commitments to a course of action. Look for:

• "Let's go with...", "We'll do...", "We decided..."
• Choosing between alternatives
• Agreeing on a direction

For each decision, assess:

• Who proposed it (who said "I think we should..." or "What if we...")
• Who decided (who gave final approval — "Sounds good", "Let's do it")
• Scope: company | product | project
• Reversibility: one-way (hard to undo — hiring, equity, pivots) | two-way (easy to change — features, tools)

Action items — be thorough. Look for ALL of these patterns:

• Explicit: "[Person] will...", "Can you...", "Take care of..."
• Volunteering: "I'll handle that", "Let me do...", "I can take..."
• Implied: If someone says they'll improve/fix/create something, that is a task
• Follow-ups: Items needing attention even without explicit assignment

Key discussion points — topics that got meaningful airtime

Summary — 2-3 sentence overview

Step 4: Redaction Judgment

This is a shared company vault. Apply judgment about what belongs in shared records.

Auto-redact (do it, no confirmation needed):

• Phone numbers, addresses, SSNs
• Financial figures (salaries, investment amounts)
• Passwords, API keys

Flag for user confirmation (use ask_user):

• Explicit removal requests ("off the record", "don't add that")
• Personal asides clearly unrelated to work

Omit entirely (don't even flag):

• HR/personnel matters — note "Personnel discussion - details in private records"
• Individual criticism of team members

When redacting, think holistically about context. A single-line gap surrounded by reactions is worse than no redaction — remove the full exchange.

Step 5: Create Entries

1. Meeting note: vault_create_entry(entry_type: "meeting", ...) with full extracted content
2. Decision records: For each decision:
   • vault_create_entry(entry_type: "decision", ...) — creates DR-YYYY-NNN automatically
   • decision_log(node_type: "decision", ...) — adds to the live decision graph with confidence score
   • vault_link(source_path: meeting, target_path: decision, link_type: "decides")
3. Action items: vault_kanban(action: "add", ...) for each task, linked to the meeting
4. Atomic notes: If discussion surfaced a reusable concept or strategy, create it as a note and link to the parent topic

Step 6: Update Prep (if exists)

If a prep file existed:

• vault_update_entry to check off covered topics (- [ ] to - [x])
• Count coverage: "Discussed X/Y agenda topics"
• Add processed: true to frontmatter

Step 7: Refresh Dashboard

vault_dashboard(dashboard_type: "activity") then use the result to update the index entry.

Step 8: Report

Summarize what was created:

• Meeting note path
• Decision records created (list with DR numbers)
• Action items added (count, grouped by assignee)
• Prep coverage (if applicable)
• Any flagged redactions that need review