--- name: transcribe-meeting description: Transcribe and summarize a meeting recording — speaker-attributed transcript, corrected mis-hearings, then a brief with decisions and action items. Use whenever the user points at an audio or video file (.mp4, .mkv, .mov, .m4a, .mp3, .wav) or a Teams/Zoom transcript export and asks to transcribe it, summarize it, take notes, write minutes, say what was discussed, who said what, what was decided, or what the action items and follow-ups are. license: MIT version: 1.1.0 metadata: gaia: security_tier: community tools_required: - transcribe_media - refine_transcript - summarize_document - query_documents - remember provenance: source: starter-pack --- # Transcribe Meeting A recording becomes a usable brief in three tool calls. Each one produces a file the next one reads — nothing is passed inline, because a 46-minute meeting is ~135,000 characters against a 60,000-character tool-result budget, and a summary built from the truncated half looks finished rather than truncated. | # | Call | Produces | |---|---|---| | 1 | `transcribe_media(file_path)` | Raw transcript at `~/.gaia/transcripts/.txt`. Returns `transcript_path`, never the text. | | 2 | `refine_transcript(transcript_path)` | A speaker-labelled markdown transcript, **already indexed**. Returns `refined_path`, `speakers`, `turns`. | | 3 | `summarize_document(refined_path, summary_type='detailed')` | The brief. | ## Procedure 1. **Confirm the file exists, and set expectations.** If the path is not there, say so and quote it — never describe a recording from its filename. Measured on a 46-minute recording: ~6 min to transcribe, ~4 min to separate the voices, ~1-2 min to name them and summarize — about 11-12 minutes, or roughly 4x realtime. Say that before you start, not after the user has waited. 2. **Transcribe.** `transcribe_media(file_path)`. Pass `output_path` to write elsewhere, `language` to skip auto-detection. The transcript is written before anything downstream runs, so it survives a later failure; if the call errors, report its message as given — it names the missing component and the command that installs it. `preview` is the first 1200 characters, for identifying the recording only. `low_confidence_spans` and `low_confidence_span_count` are informational — step 3 does the correcting. Do not repair them yourself. 3. **Refine — one call, and it is not your work to redo.** `refine_transcript(transcript_path)` groups the transcript by the voices already separated from the audio, puts names to them where the conversation supports it, writes the result and indexes it. You do not work out the speakers yourself, do not rewrite wording, and do not write a transcript file. Summarizing the raw transcript instead produces a brief with no owners on the action items. It needs the timings saved alongside the raw transcript. If it reports they are missing, re-run `transcribe_media` on the original media rather than trying to segment the text yourself — turn boundaries guessed from prose are invented, not observed. 4. **Report both paths, every time.** State the raw `transcript_path` *and* the `refined_path` in your reply — even when the user only asked for action items, even if a later step fails. Transcription costs minutes of compute; a user who does not know the files exist pays for it twice. 5. **Summarize.** `refine_transcript` already indexed the file, so go straight to `summarize_document(refined_path, summary_type='detailed')`, which folds the whole transcript forward in sections so the brief covers the entire meeting. 6. **Remember the outcome, not the transcript.** `remember` a short record of the meeting: what it was, when, who was in it, the decisions, and any action item the user personally owes. Two or three sentences. The transcript is already indexed — that is what detailed questions read from. Memory is for the durable facts that should surface *without* being asked, weeks later, when the user says "what did I commit to?" or a related topic comes up in a different conversation. Do not store the transcript, long quotes, or the full brief in memory. That duplicates the index, crowds out everything else the user asked to be remembered, and gets recalled in conversations it has nothing to do with. Store nothing when the recording turned out to be something other than a meeting. 7. **Invite the follow-up.** Close by telling the user they can ask questions about the meeting and you will answer from the indexed transcript. They will not discover this on their own. ## Never build the brief from a fragment - **Not from `preview`.** 1200 characters tells you which recording this is and nothing else — not the topic, not the participants, not the decisions, and certainly not the action items, which cluster at the end. - **Not from `query_documents`.** It returns only the top few matching chunks, so a summary built from it silently omits most of the meeting. `query_documents` *is* the right tool for a later follow-up question about a specific detail. If a stage did not run, say which one and what the brief is therefore missing. Do not present a partial pass as the finished product. ## When speaker identification did not run `transcribe_media` returns a `speaker_identification` field ONLY when voices could not be separated — the engine was missing, or the audio defeated it. When it is there, say so in your reply and give its reason. A transcript with no speaker labels reads exactly like a meeting with one participant, so silence here is not neutral: it is a wrong answer the user has no way to catch. Carry on and summarize anyway. A brief without owners still beats no brief — just do not present it as though you knew who spoke. ## Speaker names are inferred, not identified Voices ARE separated from the audio, by acoustic diarization — that part is measured, not guessed. What stays inferred is the *name* attached to each voice: `refine_transcript` reads self-introductions, direct address and role cues. So present the names as best-effort while the separation is not. Voices it could not name stay `Speaker 1`, `Speaker 2`; never upgrade one to a real name yourself. A confidently wrong name propagates into the brief, into who owns each action item, and into the indexed transcript that answers questions weeks later. ## Output shape `refine_transcript` writes: ```markdown # Transcript — staff-meeting Source: C:\recordings\staff-meeting.mp4 ## Speakers - Priya Raman - Dan Okafor - Speaker 3 ## Transcript Priya Raman: Thanks everyone for joining... Dan Okafor: The migration finished Tuesday... ``` ## Brief shape Shape your brief from `summarize_document`'s output as: what the meeting was for and what came out of it (2–3 sentences); key facts stated rather than inferred; action items with an owner each, `unknown` when the transcript does not say; and anything unresolved or blocked. This section is the one to change when a reader wants their briefs a different way — a different order, a section dropped, a section added. Everything above it is about producing a trustworthy transcript and is not a matter of taste. ## Fork this The three calls stay as they are — the file-not-inline pipeline, the speaker honesty, and refinement before summarization are what make any output trustworthy. Change only `Brief shape`: an incident review wants Timeline, Root Cause, Impact and Remediation; a customer call wants Asks, Objections, Commitments and Next Steps.