Meeting Distill
Extract long-term relevant knowledge from a meeting transcript and persist it into the docs/ folder. This skill is designed for recurring team syncs, all-hands, and planning meetings.
Argument: $ARGUMENTS
Step 1: Obtain the transcript
- If
$ARGUMENTS contains a file path, read it.
- If
$ARGUMENTS is empty or short, the transcript was likely pasted directly in the conversation. Use the conversation context.
- If no transcript is available, ask the user to paste one or provide a file path.
Step 2: Identify participants and meeting type
Scan the transcript and note:
- Who attended (names and roles, if discernible)
- Meeting type (weekly sync, all-hands, planning, 1:1, etc.)
- Date (from the transcript header or context)
Step 3: Extract long-term knowledge
Read the transcript and extract only durable knowledge - information that will still be relevant months from now. For each item, classify it:
What to extract
| Category |
What to look for |
| Product direction |
New product ideas, feature visions, strategic pivots, market positioning signals |
| Architecture/tooling |
New tools, systems, or architectural patterns being built or adopted (how they work, why they were chosen) |
| Domain knowledge |
Regulatory, scientific, or industry context that helps understand the business |
| Team/org changes |
New hires, role changes, team restructuring, new responsibilities |
| Process changes |
New workflows, changed policies, new vendor relationships that affect how work gets done |
| Client/market signals |
Patterns in client needs or market dynamics (not individual deal details) |
What to ignore
| Category |
Why |
| Status updates on in-flight work |
Ephemeral - will be outdated in days |
| Deadlines and timelines |
Ephemeral - stale immediately after the date passes |
| HR/benefits/admin announcements |
Not relevant to project context |
| Small talk, introductions of existing team members |
No knowledge value |
| Bug reports or incident details |
Belong in issue trackers, not docs |
| Specific customer names and deal values |
Business-sensitive, not engineering context (unless the client relationship reveals a product pattern) |
| Action items and to-dos |
Belong in task trackers |
Step 4: Reconcile with existing docs
Read docs/index.md to understand existing documentation structure.
For each knowledge atom:
- Find the right file - check if an existing doc covers the topic
- If a doc exists - read it, update the relevant section. Merge new information naturally into existing prose. Do not create duplicate sections.
- If no doc exists - only create a new file if the knowledge does not fit into any existing doc.
- If content contradicts existing docs - update the doc with the newer information. Add the meeting date as source context (e.g., "as of April 2026 weekly sync").
Writing conventions
- Hyphens (-) instead of em-dashes in all text
- Full sentences with pronouns and normal punctuation
- No fluff - write for an AI assistant that needs facts, not prose
- Lead with the what, then the why
- Attribute ideas to people when it helps understand the organizational context (e.g., "Matt identified the need for..." or "Samantha proposed...")
Step 5: Update docs/index.md
If any new files were created, add them to docs/index.md under the appropriate section.
Step 6: Report
Output a concise summary of what was extracted and where it was written:
Meeting: [type] - [date]
Participants: [names]
Changes:
- Updated docs/<area>/engineering.md: [what was added]
- Updated docs/<area>/overview.md: [what was added]
- Created docs/<area>/new-topic.md: [why a new file was needed]
Skipped (ephemeral):
- [1-2 sentence summary of what was intentionally left out]
Key principles
- Err on the side of excluding. If you are unsure whether something is long-term relevant, leave it out. The user can always ask you to add more.
- Never add deadlines or dates as actionable items. Dates are only useful as temporal context for when a decision was made.
- Merge, don't duplicate. Always check existing docs first. The goal is to enrich existing documentation, not create parallel files.
- Preserve existing structure. When updating a file, respect its current organization. Add new sections where they naturally fit.
- Do not use em-dashes. Use hyphens, commas, or parentheses instead.
1---2name: meeting-distill3description: Extract long-term knowledge from a meeting transcript and persist it into docs/. Filters out ephemeral content and focuses on durable architectural, product, domain, and team knowledge.4---56# Meeting Distill78Extract long-term relevant knowledge from a meeting transcript and persist it into the `docs/` folder. This skill is designed for recurring team syncs, all-hands, and planning meetings.910Argument: `$ARGUMENTS`1112## Step 1: Obtain the transcript1314- If `$ARGUMENTS` contains a file path, read it.15- If `$ARGUMENTS` is empty or short, the transcript was likely pasted directly in the conversation. Use the conversation context.16- If no transcript is available, ask the user to paste one or provide a file path.1718## Step 2: Identify participants and meeting type1920Scan the transcript and note:21- **Who attended** (names and roles, if discernible)22- **Meeting type** (weekly sync, all-hands, planning, 1:1, etc.)23- **Date** (from the transcript header or context)2425## Step 3: Extract long-term knowledge2627Read the transcript and extract **only durable knowledge** - information that will still be relevant months from now. For each item, classify it:2829### What to extract3031| Category | What to look for |32|----------|-----------------|33| **Product direction** | New product ideas, feature visions, strategic pivots, market positioning signals |34| **Architecture/tooling** | New tools, systems, or architectural patterns being built or adopted (how they work, why they were chosen) |35| **Domain knowledge** | Regulatory, scientific, or industry context that helps understand the business |36| **Team/org changes** | New hires, role changes, team restructuring, new responsibilities |37| **Process changes** | New workflows, changed policies, new vendor relationships that affect how work gets done |38| **Client/market signals** | Patterns in client needs or market dynamics (not individual deal details) |3940### What to ignore4142| Category | Why |43|----------|-----|44| Status updates on in-flight work | Ephemeral - will be outdated in days |45| Deadlines and timelines | Ephemeral - stale immediately after the date passes |46| HR/benefits/admin announcements | Not relevant to project context |47| Small talk, introductions of existing team members | No knowledge value |48| Bug reports or incident details | Belong in issue trackers, not docs |49| Specific customer names and deal values | Business-sensitive, not engineering context (unless the client relationship reveals a product pattern) |50| Action items and to-dos | Belong in task trackers |5152## Step 4: Reconcile with existing docs5354Read `docs/index.md` to understand existing documentation structure.5556For each knowledge atom:57581. **Find the right file** - check if an existing doc covers the topic592. **If a doc exists** - read it, update the relevant section. Merge new information naturally into existing prose. Do not create duplicate sections.603. **If no doc exists** - only create a new file if the knowledge does not fit into any existing doc.614. **If content contradicts existing docs** - update the doc with the newer information. Add the meeting date as source context (e.g., "as of April 2026 weekly sync").6263### Writing conventions6465- **Hyphens** (-) instead of em-dashes in all text66- **Full sentences** with pronouns and normal punctuation67- **No fluff** - write for an AI assistant that needs facts, not prose68- **Lead with the what, then the why**69- **Attribute ideas to people** when it helps understand the organizational context (e.g., "Matt identified the need for..." or "Samantha proposed...")7071## Step 5: Update docs/index.md7273If any new files were created, add them to `docs/index.md` under the appropriate section.7475## Step 6: Report7677Output a concise summary of what was extracted and where it was written:7879```80Meeting: [type] - [date]81Participants: [names]8283Changes:84- Updated docs/<area>/engineering.md: [what was added]85- Updated docs/<area>/overview.md: [what was added]86- Created docs/<area>/new-topic.md: [why a new file was needed]8788Skipped (ephemeral):89- [1-2 sentence summary of what was intentionally left out]90```9192## Key principles9394- **Err on the side of excluding.** If you are unsure whether something is long-term relevant, leave it out. The user can always ask you to add more.95- **Never add deadlines or dates as actionable items.** Dates are only useful as temporal context for when a decision was made.96- **Merge, don't duplicate.** Always check existing docs first. The goal is to enrich existing documentation, not create parallel files.97- **Preserve existing structure.** When updating a file, respect its current organization. Add new sections where they naturally fit.98- **Do not use em-dashes.** Use hyphens, commas, or parentheses instead.
lucastamoios