meeting-ingest
Ingests a meeting transcript (video-call transcript, raw notes, transcribed audio) and produces a structured note in 04-meetings/ with decisions, action items, dynamics, and participants. Automaticall
SKILL.md.claude/skills/meeting-ingest/SKILL.md
GitHubSkill: Meeting Ingest
When to activate
- The user shares a meeting transcript (text or a doc link).
- The user says: "process this meeting", "ingest", "meeting note", "analyze this meeting".
- The user uploads a file named
meet*,transcript*,recording*, or a doc of a session. - You detect the shared content is clearly a multi-speaker transcript.
Do NOT use meeting-ingest when:
- The content is < 200 words → use
braindump. - The meeting is only upcoming (pre-meeting briefing) → make a manual prep note.
- It's just the user's short notes → use
braindump.
Preflight
- Read
_CLAUDE.md(rules, structure, conventions) and00-inbox/MY-PROFILE.md(working language,sensitive-meetingslist, per-skill preferences). - Get the real timestamp of processing time.
- Determine the meeting date (priority: from the transcript / calendar invite; fallback: ask).
- Capture the source link — if the transcript comes from a Google Doc, a recording, or a
calendar event, keep its URL verbatim for the
source:field, so you can jump back to the original later. If there's no link (pasted text), setsource: "pasted transcript". - List existing notes in
02-people/and03-projects/for reference resolution. - Determine the invocation mode:
- Manual: the user invokes it explicitly → standard behavior.
- Auto: invoked by daily-brief orchestration → adapted behavior (see "Auto mode").
Source priority — transcript-first, summary fallback
Google Meet (and most call platforms) produce two Drive artifacts after a meeting:
- A transcript tab/file — full verbatim of what was said. This is the ground truth.
- A summary / AI notes tab — a model-generated digest, default tab in Drive's preview. This is lossy: it drops dynamics, side-discussions, contested exchanges, the exact wording of decisions, and most action-item nuance.
Rule: when ingesting from a Drive doc / Meet artifact, you ALWAYS read the transcript first. The summary is a fallback, not a default.
Decision tree
- Transcript available (transcript tab populated, or a separate
*-transcript.docx/*.vttnext to the recording in Drive) → use the transcript verbatim as the source. Recordtranscript-source: verbatimin frontmatter. - Transcript missing but summary available → fall back to the summary. Mark the meeting
note with degraded confidence:
confidence: mediumin frontmatter.transcript-source: summary-fallbackin frontmatter.- "For future Claude" preamble must state explicitly:
*Source: summary tab (transcript unavailable). Information loss expected — dynamics, exact decision wording, and side-discussions are not captured.* needs-review: true(the user may want to re-process if the transcript appears later).
- Neither available → do not ingest. Flag in the brief for manual handling.
Why this matters
Summaries elide ~40-60% of useful signal: the framing of disagreement, the exact phrasing of
commitments, the moments of hesitation that reveal real risk. challenge-decision and
people-update rely on those nuances. Defaulting to the summary tab is the single biggest
quiet quality leak in the orchestration — don't take it.
Auto mode (invoked by daily-brief)
When this skill is invoked by daily-brief orchestration (not directly by the user):
Behavioral differences
- Frontmatter:
ingestion-mode: autoandneeds-review: true. - "For future Claude" preamble explicitly states:
*Auto-ingested via daily-brief on YYYY-MM-DD. needs-review flag is true until the user confirms during morning review.* - Hard-to-reverse decisions: flag
needs-validation: truein the meeting note rather than auto-creating a dedicated05-decisions/note. The user creates the decision note later if they validate. - Newly detected people: no auto-creation of a stub. List them for the user to validate.
- Ambiguous participant fuzzy-match: use the best guess but flag
needs-reviewinstead of asking interactively. - No user interaction: if critical data is missing, insert an explicit placeholder with
⚠️ to verify on reviewrather than a question (the scheduler runs autonomously).
Auto-ingestion guardrails
Auto-ingest ONLY if ALL of these are true:
- ✅ Matches a calendar event (title / participants / time).
- ✅ Participants ≥ 2 including the user.
- ✅ Calendar duration ≥ 15 minutes.
- ✅ NOT in the
sensitive-meetingslist of00-inbox/MY-PROFILE.md. - ✅ NOT already ingested (cross-check
04-meetings/).
If any condition fails → do NOT ingest. daily-brief flags it for manual validation.
Source choice (auto mode): the transcript-first rule (see Source priority) applies the
same way in auto mode. If only the summary is available, daily-brief still ingests but with
the degraded markers (confidence: medium, transcript-source: summary-fallback,
needs-review: true) and a one-line callout in the brief: "N meetings ingested from
summary only — transcript missing."
"Post-auto validation" mode
When the user later invokes meeting-ingest on an already auto-ingested note
(signal: "validate the meeting from Tuesday with [X]"):
- Read the existing note.
- Re-process the original transcript if available.
- Enrich the sections (especially decisions, action items, dynamics) with a more critical eye.
- Update frontmatter:
ingestion-mode: auto-validatedandneeds-review: false. - Note in the "For future Claude" preamble:
*Validated by the user on YYYY-MM-DD.* - Append-only: keep the original auto-ingest sections; add "Validation notes" if needed.
Process
Step 1 — Initial parsing
Identify from the transcript:
- Meeting date and time (if not in the transcript frontmatter, search the content).
- Duration (start/end timestamps if available).
- Participants: names, roles if mentioned.
- Meeting type: 1-1 | team-sync | stakeholder | external | townhall.
- Main topic: one summarizing sentence.
If ambiguous, ask ONE clarification (priority: type + associated project).
Step 2 — Participant resolution
For each identified participant:
- Fuzzy-match against
02-people/*.md. - Unique match → direct wikilink.
- Multiple matches → list to the user for a choice.
- No match → offer to create a stub (with the role inferred from the transcript).
- Always confirm before creating a new person note.
Step 3 — Noise filtering
Remove from the transcript:
- Off-topic side chats.
- Technical difficulties ("you're on mute", "can you see my screen").
- Opening/closing pleasantries.
- Exact repetitions.
⚠️ Keep verbatim the sentences that:
- Contain a decision.
- Commit someone to an action.
- Express a disagreement or tension.
- Give a number / a verifiable fact.
Step 4 — Structured extraction
For each section below, be exhaustive but factual:
4.1 Decisions
For each decision:
- What: the decision itself (one clear sentence).
- Why: the stated rationale (verbatim if possible).
- Who: decision-maker(s) — wikilinks.
- Reversibility: reversible | hard-to-reverse | one-way.
- Impacted stakeholders: wikilinks.
4.2 Action items
For each action:
- What: concrete action.
- Owner: wikilink (else "unassigned" + flag).
- Deadline: date if mentioned, else "unspecified".
- Depends on: if applicable.
4.3 Strategic themes
2–4 themes max. No fluff — substantive angles.
4.4 Key quotes
The sentences worth keeping verbatim (citations, strong positions, useful phrasings).
4.5 Tensions and disagreements
If present: who vs. whom, on what, status (resolved / open).
4.6 Unresolved
What should have been settled and wasn't. With a proposed next step.
Step 5 — Dynamics analysis (optional, by meeting type)
For 1-1s and stakeholder meetings, add a dynamics section:
- Participation / notable silences.
- Leadership moments.
- Perceived energy level.
- Weak signal worth digging into.
Skip for townhalls / team-syncs.
Step 6 — Generate the note
Path: 04-meetings/YYYY-MM-DD-<slug>.md
The <slug> reflects the topic, not the format
(stakeholder-review-onboarding rather than tuesday-meeting).
Required format:
---
date: YYYY-MM-DD # meeting date
ingested: YYYY-MM-DD # ingestion date
type: meeting
tags: [meeting, <project-tags>, <topic-tags>]
participants: ["[[02-people/...]]", ...]
project: "[[03-projects/...]]" # optional if cross-cutting
meeting-type: 1-1|team-sync|stakeholder|external|townhall
duration: <min>
source: "<verbatim link to the transcript / Google Doc / recording, or 'pasted transcript'>"
transcript-source: verbatim | summary-fallback # which Drive tab/file was ingested
confidence: high | medium # medium when transcript-source: summary-fallback
ai-first: true
---
## For future Claude
This is the ingested record of a [meeting-type] held on [date] with [participants].
It covered [main topic]. Key outcomes: [N decisions, N action items]. [Note any
unresolved item or follow-up.]
## Context
[2-3 sentences: why this meeting, what preceded it, the situation at the time.]
## Participants
- [[02-people/Name 1]] — role in the meeting
- [[02-people/Name 2]] — role in the meeting
## Decisions
### [Short decision title]
- **What**: [decision]
- **Why**: "[verbatim or paraphrased rationale]"
- **Decision-maker(s)**: [[02-people/...]]
- **Reversibility**: reversible|hard-to-reverse|one-way
- **Impact**: [[02-people/...]], [[03-projects/...]]
[Repeat for each decision]
## Action items
<!-- Each line carries owner, due date, #from/meeting tag, and a ^t-id anchor for TODO.md sync -->
- [ ] [Action] — owner: me — due: YYYY-MM-DD — #from/meeting ^t-xxxxxx
- [ ] [Action] — owner: [[02-people/...]] — due: YYYY-MM-DD — #from/meeting ^t-xxxxxx
- [ ] [Action] — owner: unassigned ⚠️ — due: unspecified — #from/meeting ^t-xxxxxx
## Strategic themes
1. **[Theme 1]**: [1-2 sentences]
2. **[Theme 2]**: [1-2 sentences]
## Key quotes
> "[Verbatim quote]" — [[02-people/Name]], about [context]
## Tensions / Disagreements
[Optional section, skip if nothing to report.]
## Unresolved
- [Open question] — proposed next step: [action]
## Dynamics
[Optional section, mainly for 1-1 and stakeholder meetings.]
## Links
- Source: [original transcript / Google Doc / recording link, if any]
- People: [all participant + mentioned wikilinks]
- Projects: [wikilinks to discussed projects]
- Related decisions: [[05-decisions/...]] if a major decision was logged separately
- Previous meetings: [[04-meetings/...]] if part of a series
Step 7 — Propagation (CRITICAL)
This step is what keeps the system alive. Do NOT skip it.
7.1 Update people notes
For each participant existing in 02-people/:
- Append a Timeline entry:
- YYYY-MM-DD: [[04-meetings/<slug>]] — [one sentence on what happened for this person]. - Update
last-interactionin the frontmatter. - Append-only: never overwrite.
7.2 Update project notes
For each project referenced in 03-projects/:
- Append to the "Timeline" section:
- YYYY-MM-DD: meeting [[04-meetings/<slug>]] — [main outcome]. - If decisions were made, append to the project's "Key decisions".
- Update
updated:in the frontmatter.
7.3 Important decisions → 05-decisions/
If a decision is hard-to-reverse or one-way, also create a dedicated note in
05-decisions/YYYY-MM-DD-<slug>.md. These notes are the database for challenge-decision.
7.4 Wiki stubs for new concepts / entities (+ curator incremental)
Scan the transcript and the extracted note for things the user might want to look up
later — concepts, tools, teams, processes, jargon, vendors. For each that does NOT already
exist as 06-knowledge/<slug>.md:
- Create a wiki stub per the Wiki stub protocol in
.claude/skills/knowledge-build/SKILL.md(Mode A.2).type: wiki,needs-review: true,domain: <inferred>(from project / tags / MY-PROFILE knowledge-domains; elseunsorted),created-from: "[[04-meetings/<this-meeting>]]", one verbatim 1-line snippet from the transcript in## Sources. - Backlink from the meeting note's
## Links → Related wiki. - Call curator incremental (Mode C.1 of
knowledge-build) so the new wiki page lands in the right06-knowledge/<domain>.mdhub and the root_INDEX.mdrefreshes. Silent forauto-maintained: truehubs. - If the meeting just enriches an existing wiki page, append new facts with citation to
that page (Mode A.4) and call curator incremental for
## Recent activity.
In auto mode (called by daily-brief), stubs are created silently with needs-review: true — they're surfaced in the brief for the user to confirm/enrich.
7.5 Daily note
Append to 01-daily/YYYY-MM-DD.md (ingestion date) under ## Meetings ingested today:
- [[04-meetings/<slug>]] — [meeting-type] with [main participants]
7.6 Action items
Keep the action items in the meeting note (with ^t-id anchors). The ones the user
owns are consolidated into the vault-root TODO.md by task-roundup (and by
daily-brief's roundup phase) — no need to duplicate them anywhere else.
Step 8 — Report
✓ Meeting ingested: 04-meetings/2026-05-20-stakeholder-review-onboarding.md
✓ 3 participants linked: [[Alex Rivera]], [[Jordan Park]], [[Sam Lee]]
✓ 2 people notes updated (timeline + last-interaction)
✓ Project [[03-projects/Onboarding Refresh]] updated
✓ 1 major decision logged: 05-decisions/2026-05-20-centralize-tier1.md
✓ Daily note for 2026-05-20 updated
→ 2 unassigned action items ⚠️: owners need clarifying
→ 1 unresolved tension detected: "ownership of QA training" between Alex and Jordan
→ Suggestion: invoke challenge-decision on the tier-1 centralization (one-way, high impact)
Anti-patterns to avoid
❌ Keeping everything — filter the noise (mute, technical issues, side chats). ❌ Summarizing everything — preserve decisions and key quotes verbatim. ❌ Skipping propagation — step 7 is non-negotiable. ❌ Default owner — if no clear owner, flag with ⚠️, never assign arbitrarily. ❌ Inventing dates — if no deadline is mentioned, write "unspecified". ❌ Creating people without confirmation — for new names, ask the user.
Special cases
Multilingual transcript
Teams are often international. If a meeting is in English with a few phrases in another language, keep the original language in the quotes. The rest of the note stays in English (consistent with the AI-first preamble).
Low-quality transcript (raw voice-to-text)
If there are many ASR errors, flag it in the "For future Claude" preamble:
Note: transcript quality is low (ASR errors). Verbatim quotes may contain transcription errors.
Recurring meeting (weekly 1-1, weekly sync)
Detect a series (same participants, same cadence). Link to the previous meeting in the series under "Links > Previous meetings".
1-1 with a direct report
These meetings are often the most frequent and strategic. Be more thorough on
dynamics, objective tracking, and the report's development. Systematically link
to the relevant [[03-projects/...]] coaching/development project if one exists.