skinnyandbald/process-meeting-notes

<essential_principles>

How This Skill Works

This skill processes meeting transcripts from Fireflies and Plaud with mandatory full transcript analysis — not just automated summaries. It extracts action items from ALL participants, routes GitHub issues to the correct repository via smart detection, and runs a deterministic verification script to ensure no items are dropped. It works with any repository you're currently in.

Principle 1: Mandatory Full Transcript Analysis

Fetch meeting data from the appropriate source:

Fireflies MCP:

• mcp__fireflies__fireflies_search to find meetings
• mcp__fireflies__fireflies_get_summary for action items, keywords, overview
• mcp__fireflies__fireflies_get_transcript — ALWAYS fetch the full transcript; it is mandatory, not optional

Plaud MCP (optional):

• mcp__plaud__list_files to browse/find recordings
• mcp__plaud__get_transcript for timestamped transcript with speaker labels

Do NOT use mcp__plaud__get_note. The skill generates its own structured summary and action items by analyzing the full transcript — Plaud's built-in AI notes are lower quality than what this skill produces. The only Plaud tools needed are list_files (to find recordings) and get_transcript (to get raw dialogue).

Plaud tools are optional. If Plaud MCP is not configured in the current environment, skip Plaud steps gracefully and process Fireflies-only. Do not fail or error when Plaud tools are unavailable.

For both sources: a subagent must read the entire transcript to extract action items, decisions, and key discussion points. The skill generates all summaries itself from the raw transcript — never from a third-party AI summary.

Principle 1b: Transcript File Format (CRITICAL)

When saving transcripts to the vault, ALL transcripts MUST use normalized Fireflies format regardless of source:

Speaker Name: Content of what they said in this segment.
Speaker Name: Next thing they said.
Other Person: Their response.

Rules:

• One line per speech segment
• Format: Speaker Name: content — no timestamps, no bold, no brackets
• Use the speaker's real name when available (from Plaud speaker field or Fireflies attribution)
• NO [MM:SS - MM:SS] timestamps, NO **Speaker:** bold formatting
• The transcript body is raw dialogue only — no markdown headers or summary sections

For Plaud specifically:

• Call get_transcript (NOT get_note) to populate the transcript file
• Parse the returned JSON segments: each has {content, speaker, start_time, end_time}
• Convert each segment to one line: {speaker}: {content}
• NEVER save get_note output (AI summary) to the transcripts folder — that goes in the structured meeting note only

For Fireflies:

• Call fireflies_get_transcript — it natively outputs in the correct speaker-attributed format

Principle 1c: Source ID in Frontmatter (MANDATORY)

Every transcript file MUST include the source recording ID in YAML frontmatter:

• Plaud recordings: plaud_id: <file_id from Plaud>
• Fireflies recordings: fireflies_id: <transcriptId from Fireflies>
• Pasted transcripts (source: pasted): exempt — no provider ID exists

This is the deduplication key for the unprocessed inbox workflow. Never skip it for Plaud or Fireflies sources.

Principle 2: Dynamic Repository Context

At workflow start, detect the current repository:

• Repository owner and name via gh repo view
• Available labels via gh label list
• Available milestones via GitHub API
• GitHub Projects (if any exist)

Never hardcode repo-specific values. Always detect dynamically.

Principle 3: Compare Before Creating

Before creating new GitHub issues:

1. Search existing issues in the current repository for potential duplicates
2. Check against project milestones (whatever naming convention the repo uses)
3. If related issue exists, suggest commenting/updating rather than duplicating

Principle 4: Prompt for Confirmation

For each potential GitHub issue:

• Show extracted action item
• Display suggested labels (from detected available labels)
• Ask user to confirm/modify before creation
• Never auto-assign (leave unassigned)

Principle 5: EOS Level 10 Format

All meeting summaries follow the Level 10 Meeting structure:

• Clear accountability (WHO is responsible)
• Specific deliverables (WHAT is agreed)
• Time-bound commitments (WHEN is the deadline)

Principle 6: Action Items as Checklists

Action items MUST always use markdown checkbox format — never tables or plain bullets:

- [ ] Action description -- **Owner Name** (due date)

This enables Obsidian task tracking and interactive checkboxes.

Principle 7: CRM Pipeline Awareness

After saving to vault (Step 7), detect whether the meeting is CRM-relevant (sales, discovery, client, or diagnostic). If so, check Attio for existing deals, propose stage transitions and task updates, and execute only after user confirmation.

Detection uses short-circuit evaluation to avoid unnecessary API calls:

1. Check attio_deal_id in frontmatter — signal 4 (validate deal exists before trusting)
2. Check meeting_type (sales/discovery/client/diagnostic) — signal 1, local, no API
3. Check Fireflies/Plaud keywords — signal 2, local, no API
4. Query Attio for active deal linkage — signal 3, only as tiebreaker when exactly 1 local signal exists Zero-signal meetings never touch the Attio API.

Key constraints:

• MCP create_record cannot create deals (owner field unsupported). Use REST API via curl when deal creation is needed.
• Only deal-advancing tasks go to Attio (per attio-task-scope.md). Everything else stays as GitHub issues.
• All changes are collected and presented for confirmation before execution.
• On partial failure: log pending changes to temp file, warn user, do not continue silently.

See references/attio-crm-integration.md for deal stages, task templates, MCP tool inventory, and REST API curl template.

Principle 8: Issue Hierarchy — Parent Issues with Sub-Issues

When a meeting produces 2+ action items for the same source (meeting, project, participant cluster), do NOT create N flat standalone issues. Apply hierarchy:

1. Single item from a source → standalone issue
2. 2+ items from a source → create a parent issue first, then:
   • Simple items (send a link, read something) → checklist in parent body
   • Complex items (needs own research thread, labels, multi-step) → native sub-issue via REST API

Creating sub-issues via API:

CHILD_ID=$(gh api repos/OWNER/REPO/issues/$CHILD_NUM --jq '.id')
echo "{\"sub_issue_id\": $CHILD_ID}" | gh api repos/OWNER/REPO/issues/$PARENT_NUM/sub_issues --method POST --input -

Critical: sub_issue_id is the REST API id (large integer), NOT the issue number. -f sends strings and causes 422 — pipe JSON with --input -.

Cross-repo and cross-org both work. Because sub_issue_id is the globally-unique REST id, a parent can attach a child in any repo you can access — same owner (skinnyandbald/SecondBrain ↔ skinnyandbald/distil) or a different owner/org. There is no same-owner restriction. The only cause of a 422 here is the wrong id (the issue number or node_id instead of the integer id, or -f string encoding) — both covered above. (Verified against the live GitHub API on 2026-06-01: a cross-owner attach returns 201 Created.)

See the Issue Hierarchy decision tree in the workflows/process-recent-meeting.md (Step 5.75) for the full grouping logic and parent body format. </essential_principles>

<configuration> ## Optional: Vault Integration

If you want meeting notes and transcripts saved to a personal knowledge base (Obsidian vault, SecondBrain, etc.), set these environment variables or define them in your project's CLAUDE.md:

| Variable | Purpose | Example | |----------|---------|---------| | MEETING_NOTES_DIR | Where structured meeting notes are saved | ~/SecondBrain/02_Areas/notes | | MEETING_TRANSCRIPTS_DIR | Where raw transcripts are archived | ~/SecondBrain/02_Areas/notes/transcripts |

If not set: The skill will only generate GitHub issues and L10 summaries without saving to a vault. It will ask the user where to save if they request it.

If set: The skill automatically saves:

1. Structured meeting note to $MEETING_NOTES_DIR/YYYY-MM-DD - Entity - Topic.md
2. Raw transcript (when piped in directly or fetched from Fireflies) to $MEETING_TRANSCRIPTS_DIR/YYYY-MM-DD - Source - Topic.md

File Naming Convention

Notes: YYYY-MM-DD - Entity - Topic.md (e.g., 2026-03-13 - Hampton - Core Meeting.md) Transcripts: YYYY-MM-DD - Source - Topic.md (e.g., 2026-03-13 - Fireflies - Hampton Core Meeting.md)

Transcript Frontmatter

---
date: YYYY-MM-DD
type: transcript
source: fireflies | pasted | plaud
fireflies_id: <transcript_id>  # required when source: fireflies
plaud_id: <file_id>            # required when source: plaud
meeting_type: sales | internal | peer-advisory | other
attendees: [...]
processed_note: "YYYY-MM-DD - Entity - Topic.md"
---

The processed_note field links the raw transcript to its structured meeting note. </configuration>

<intake> What would you like to do?

0. Process unprocessed inbox - Scan Fireflies and Plaud for unprocessed meetings, walk through each one
1. Process recent meeting - Analyze the most recent meeting from Fireflies or Plaud and extract action items
2. Search specific meeting - Find a meeting by date, keyword, or participant
3. Create issues from notes - I already have meeting notes to convert to GitHub issues
4. Generate L10 summary only - Create EOS Level 10 summary without creating issues

If invoked with no arguments, default to option 0.

Wait for response before proceeding. </intake>

<routing> | Response | Workflow | |----------|----------| | 0, no args, "unprocessed", "inbox" | `workflows/process-unprocessed-inbox.md` | | 1, "recent", "latest", "today" | `workflows/process-recent-meeting.md` | | 2, "search", "find", "specific" | `workflows/search-meeting.md` | | 3, "create", "notes", "issues" | `workflows/create-issues-from-notes.md` | | 4, "summary", "L10", "EOS" | `workflows/generate-l10-summary.md` |

After reading the workflow, follow it exactly. </routing>

<reference_index> All domain knowledge in references/:

EOS Framework: eos-level-10-format.md GitHub Integration: github-project-config.md (dynamic detection patterns) Attio CRM Integration: attio-crm-integration.md (deal stages, MCP tools, task templates, REST API) </reference_index>

<workflows_index> | Workflow | Purpose | |----------|---------| | process-unprocessed-inbox.md | Scan Fireflies + Plaud for unprocessed meetings, present queue, walk through each | | process-recent-meeting.md | Full workflow: detect context → fetch → compare → create issues → L10 summary | | search-meeting.md | Find specific meeting by criteria | | create-issues-from-notes.md | Convert provided notes to GitHub issues | | generate-l10-summary.md | Create L10 summary from existing analysis | </workflows_index>

<templates_index> | Template | Purpose | |----------|---------| | l10-meeting-summary.md | EOS Level 10 Meeting summary structure | | github-issue-checklist.md | Issue body with implementation checklist | </templates_index>