Meeting Minutes Taker
Audit and strengthen meeting minutes against transcripts so decisions, quotes, entities, and owned action items are complete before you commit specs to the repo.
Overview
Meeting Minutes Taker is an agent skill most often used in Build (also Validate, Grow) that reviews meeting minutes for completeness, quotes, and owned action items against the transcript.
Install
npx skills add https://github.com/daymade/claude-code-skills --skill meeting-minutes-takerWhat is this skill?
- 4-phase completeness review: structural, content depth, quotes, and action items
- Content depth checks: entities, numerical values, state machines, architecture, trade-offs, constraints
- Merge strategy rules for combining multiple minute versions
- Red flags list for common omissions (technical, business logic, process)
- Requires decision quotes, named owners, and priorities on every action item
- 4-phase completeness review process
- 4 structural checklist categories in phase 1
- Documents common omission patterns across technical, business, and process items
Adoption & trust: 587 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your meeting notes miss entities, numbers, or named owners, so downstream specs and agent tasks drift from what was actually decided.
Who is it for?
Solo founders who run customer or cofounder calls and feed minutes into Claude Code planning or issue trackers.
Skip if: Live meeting facilitation or scheduling—use when you already have a transcript or draft minutes to audit.
When should I use this skill?
User has meeting transcripts or draft minutes and needs a completeness review, merge strategy, or action-item audit before trusting the doc for specs.
What do I get? / Deliverables
You get checklist-driven gaps filled and merge-ready minutes with attributed quotes and prioritized, owner-specific action items.
- Reviewed minutes with gap list addressed
- Verified quotes and prioritized action items with owners
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Meeting output most often feeds Build planning—turning calls into trustworthy specs and task lists solo founders actually execute. PM subphase is where minutes become scope, owners, and priorities; this skill is the quality gate on that artifact.
Where it fits
After a discovery call, confirm MVP boundaries and rejected alternatives are quoted before you prototype.
Technical sync minutes checked for entity models, state transitions, and Alice/Bob-specific tasks.
Customer success call minutes audited so support priorities and explicit assignments enter the backlog.
How it compares
Use as a structured review pass instead of asking the model to summarize a call once without verification steps.
Common Questions / FAQ
Who is meeting-minutes-taker for?
Indie builders and small teams who document decisions in meetings and need those minutes to survive handoff to implementation plans or tickets.
When should I use meeting-minutes-taker?
In validate when scoping from stakeholder calls; in build/pm after technical design meetings; in grow when customer feedback sessions need quoted decisions and follow-ups.
Is meeting-minutes-taker safe to install?
It processes meeting text you provide—avoid pasting secrets; review the Security Audits panel on this page before installing from an untrusted source.
SKILL.md
READMESKILL.md - Meeting Minutes Taker
# Meeting Minutes Review Checklist ## Contents - Completeness Review Process (4 phases: structural, content depth, quotes, action items) - Common Omission Patterns (technical, business logic, process items) - Merge Strategy (multi-version union rules) - Red Flags (signs of missing content) ## Completeness Review Process ### Phase 1: Structural Check - [ ] All major discussion topics from transcript are covered - [ ] Each decision has supporting quote - [ ] All speakers who made decisions are attributed - [ ] Action items have specific owners (not generic "team") - [ ] Priorities assigned to all action items ### Phase 2: Content Depth Check For each transcript section, verify: - [ ] **Entities/Data Models**: All mentioned entities captured (tables, fields, relationships) - [ ] **Numerical Values**: Ranges, priorities, counts preserved (e.g., "0-99", "4 states", "3-4 categories") - [ ] **State Machines**: All states and transitions documented - [ ] **Architecture Decisions**: Data flow, dependencies, integration points - [ ] **Trade-offs**: Rejected alternatives and reasoning - [ ] **Constraints**: Technical limitations, MVP scope boundaries ### Phase 3: Quote Verification For significant decisions, ensure: - [ ] Quote accurately reflects speaker's point - [ ] Speaker attribution is correct - [ ] Context around quote is preserved ### Phase 4: Action Items Audit Cross-reference with transcript for: - [ ] Explicit task assignments ("Alice will handle...", "Bob, please...") - [ ] Implicit commitments ("I will design...", "Backend team will...") - [ ] Deferred items ("Defer to later...", "Not in MVP scope...") - [ ] Follow-up discussions needed ("Discuss offline...", "Follow up separately...") ## Common Omission Patterns ### Technical Details Often Missed 1. **Entity Hierarchies**: Category → Subcategory → Item → Detail 2. **Field Definitions**: What fields belong to which entity 3. **Calculation Rules**: Priority orders, workflow logic, matching rules 4. **Storage Decisions**: Where data is persisted, what's cached 5. **API Contracts**: Who calls whom, sync vs async ### Business Logic Often Missed 1. **State Transitions**: What triggers state changes 2. **Permission Rules**: Who can do what 3. **Validation Rules**: Required fields, constraints 4. **Display Logic**: What's shown where, sorting rules 5. **Integration Points**: Cross-system data sharing ### Process Items Often Missed 1. **Design Approach**: Joint vs separate design decisions 2. **Dependency Order**: What blocks what 3. **Offline Follow-ups**: Items requiring separate discussion 4. **Scope Deferrals**: What's explicitly pushed to Phase 2 ## Merge Strategy (Multi-Version Union) When merging versions: 1. **Keep ALL content from existing version** - Never remove unless explicitly wrong 2. **Add NEW content from incoming version** - Union, not replace 3. **Resolve conflicts by combining** - Include both perspectives 4. **Preserve more detailed version** - When same topic has different depth 5. **Maintain structure** - Keep section numbering logical ### Merge Checklist - [ ] All sections from original preserved - [ ] All sections from new version added (or merged into existing) - [ ] No duplicate content (consolidate if same info appears twice) - [ ] Quotes from both versions preserved - [ ] Action items from both versions merged - [ ] Numbering remains sequential ## Red Flags (Signs of Missing Content) - Transcript mentions a topic not in minutes - Decision recorded without quote - Action item without clear owner - Long transcript section summarized in one sentence - Technical discussion with no entity/field names - "TBD" items without clear description - State machine with fewer states than mentioned - Priority/order system without number ranges # Project Context File Template Use this template to create a `context.md` file for your project. This file helps the skill: - Correctly identify speakers in transcripts - Use proper terminology and na