process-meeting-notes

<essential_principles>

How This Skill Works

This skill processes meeting transcripts from Fireflies with mandatory full transcript analysis — not just the Fireflies automated summary. 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

Always fetch meeting data via Fireflies MCP tools:

• 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

The Fireflies automated summary is a starting point. A subagent must read the entire transcript to extract additional action items that Fireflies missed. The verification script confirms no items were dropped.

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. </essential_principles>

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
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.

1. Process recent meeting - Analyze the most recent Fireflies meeting 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

Wait for response before proceeding.

After reading the workflow, follow it exactly.

<reference_index> All domain knowledge in references/:

EOS Framework: eos-level-10-format.md GitHub Integration: github-project-config.md (dynamic detection patterns) </reference_index>

<workflows_index>

Workflow	Purpose
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>