process-meeting-transcript
Process Meeting Transcript
Overview
Process raw meeting transcripts into well-structured Obsidian notes with YAML frontmatter, extracted action items, meeting summary, and properly formatted transcript sections.
When to Use This Skill
Use this skill when:
- User provides a raw meeting transcript (typically from Granola)
- User asks to "process a meeting transcript" or "format meeting notes"
- User points to a file containing an unprocessed transcript
- User pastes transcript content directly into the conversation
Workflow
Step 1: Read the Transcript
If the transcript is in a file, read the entire contents. If the user pasted the transcript directly, use that content.
Step 2: Extract Action Items
Carefully review the entire transcript to identify all action items, tasks, and commitments. Look for:
- Explicit commitments: "I'll do X", "Alex will review Y"
- Assigned tasks: "Nathan and Damian should schedule..."
- Follow-up items: "We need to...", "Let's make sure to..."
- Decisions requiring action: "We should deploy X before Y"
Format action items as:
- Bulleted list under
# Action Itemsheading - Use bold for person names when specific people are assigned
- Include context for what needs to be done and why
- Order by priority/importance when evident from discussion
Example format:
# Action Items
- **Alice & Bob**: Review the new feature implementation next week and provide feedback
- **Charlie & Dana**: Schedule a knowledge transfer session on the payment service architecture
- **Eve**: Discuss deployment timeline with the infrastructure team
Step 3: Create Meeting Summary
Write a comprehensive but concise summary that captures:
- Main topics discussed
- Key decisions made
- Technical architecture or approach agreed upon
- Timeline and next steps
- Important context or constraints
Structure the summary with:
- Opening paragraph: High-level overview of what was discussed and main outcome
- Subsections (using
##or###headings) for major topics - Use bold for important terms, decisions, or concepts
- Include enough detail that someone who wasn't in the meeting can understand what happened
Keep summaries factual and focused on outcomes, decisions, and technical details.
Step 4: Format the Transcript
Place the raw transcript under a # Transcript heading. Preserve the original formatting but ensure it's readable. If the transcript includes metadata (meeting title, date, participants) at the top, keep that information.
Step 5: Add Frontmatter
Use the add-frontmatter slash command to generate appropriate YAML frontmatter for the note. The frontmatter should include:
title: Meeting title or topicdate: Meeting date (YYYY-MM-DD format)type: Set to "meeting"attendees: Array of participant namesproject: Related project if applicabletags: Relevant tags (meeting, project tags, topic tags)status: Set to "complete"key_topics: Array of main discussion topicsaction_items: Array of action items (duplicate from Action Items section for searchability)decisions: Array of key decisions maderelated_links: Any links mentioned (Notion docs, Linear issues, etc.)
Invoke the add-frontmatter command by providing it with context about the meeting.
Step 6: Assemble the Final Note
Combine all sections in this order:
- YAML frontmatter (from add-frontmatter command)
- Links section (if any Notion/Linear/GitHub links were mentioned)
# Action Itemssection# Summarysection# Transcriptsection
Output Format
The final note should follow this structure:
---
title: Meeting Title
date: YYYY-MM-DD
type: meeting
attendees: ['Person 1', 'Person 2', ...]
project: Project Name
tags: [meeting, relevant, tags]
status: complete
key_topics:
- Topic 1
- Topic 2
action_items:
- 'Action item 1'
- 'Action item 2'
decisions:
- Decision 1
- Decision 2
related_links:
- 'Link description: URL'
---
**Agenda** https://link-to-agenda-if-available
# Action Items
- **Person**: Action item description
- **Person**: Another action item
# Summary
Opening paragraph with high-level overview.
## Key Decisions/Topics
Details about decisions and topics discussed...
# Transcript
[Raw transcript content]
Tips for Quality Output
- Be thorough with action items: Don't miss commitments buried in discussion
- Capture decisions: Explicit decisions are critical for reference
- Include technical details: Preserve architecture discussions, API names, service names
- Maintain context: Someone reading later should understand what was decided and why
- Preserve links: Notion docs, Linear issues, GitHub PRs mentioned in meetings are important
- Use consistent formatting: Follow the example structure for all transcripts
More from dgalarza/claude-code-workflows
tdd-workflow
Use this skill whenever you are implementing a feature using TDD.
37conventional-commits
This skill should be used when creating Git commits to ensure they follow the Conventional Commits specification. It provides guidance on commit message structure, types, scopes, and best practices for writing clear, consistent, and automated-friendly commit messages. Use when committing code changes or reviewing commit history.
31linear-implement
This skill should be used when implementing features from Linear issues with full TDD workflow, automated planning, parallel code reviews (security and Rails best practices), systematic feedback implementation, and automated PR creation with Linear integration. Use when the user provides a Linear issue ID (e.g., "TRA-9", "DEV-123") and wants a complete implementation workflow from issue to PR.
29rspec-testing
This skill should be used when writing, reviewing, or improving RSpec tests for Ruby on Rails applications. Use this skill for all testing tasks including model specs, controller specs, system specs, component specs, service specs, and integration tests. The skill provides comprehensive RSpec best practices from Better Specs and thoughtbot guides.
19parallel-code-review
This skill should be used when performing comprehensive code reviews using multiple specialized review agents in parallel. It provides patterns for concurrent execution, decision tracking to prevent redundancy, and consolidated reporting. Use when needing thorough review coverage from multiple perspectives (security, architecture, performance) or when reviewing large changesets.
19gridfinity-baseplate-planner
Use this skill when planning and designing gridfinity baseplates for 3D printing. This includes calculating optimal grid sizes from given measurements, determining how to slice large grids into printable chunks based on printer bed dimensions, and calculating padding requirements for non-exact fits. The skill handles both metric and imperial measurements and provides guidance for using gridfinity.perplexinglabs.com to generate the actual STL files.
16