process-meeting-notes

Installation
SKILL.md

<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>
Related skills
Installs
28
GitHub Stars
1
First Seen
Feb 18, 2026