What this prompt does
This prompt frames the model as a Gemini multimodal specialist that designs an audio-analysis pipeline for [audio_type] content on Gemini [model_version]. It covers six stages: ingestion and chunking, transcription with speaker diarization, a content-analysis layer, topic segmentation and indexing, domain-specific analysis templates, and an output-and-integration step.
The chunking logic is the part that makes long audio workable. Files up to [max_duration] get split into [chunk_duration] segments with [overlap_duration] overlap so context survives the boundaries, and transcripts are merged while reconciling speaker labels. The analysis layer is shaped by [summary_length], [key_point_count], and the [output_schema] JSON schema, which is what makes downstream automation into [integration_target] reliable instead of brittle.
The design separates transcription from interpretation, which is why it scales. Diarization and timestamps come first so the raw record is searchable, then a second pass extracts summary, decisions, action items, and per-speaker sentiment against a fixed schema. Topic segmentation adds time-bounded sections written to [search_engine], turning a flat recording into something a user can search and jump into. The [secondary_audio_type] variable lets you build a second family of extraction templates, since a meeting and a podcast need different questions asked of them.
When to use it
- You want meetings, interviews, or
[secondary_audio_type]turned into searchable, structured data. - Recordings exceed Gemini's single-pass limit and need chunked processing.
- You need speaker diarization, not just a flat transcript.
- You want a topic index in
[search_engine]so users can jump to the exact moment. - You need action items pushed automatically into
[integration_target]. - You want a webhook that triggers processing whenever new audio lands in
[storage].
Example output
Expect a six-part build plan: an ingestion routine that splits audio into [chunk_duration] chunks tracked in [job_store], a diarized transcription prompt, a content-analysis step emitting JSON against [output_schema] (executive summary, [key_point_count] key points, action items, decisions, sentiment), a topic-segmentation routine writing to [search_engine], [template_count] reusable domain templates, and an export step producing [export_formats] plus webhook automation.
Pro tips
- Match
[chunk_duration]and[overlap_duration]to your audio; too little overlap drops context at boundaries, too much wastes tokens. - Define
[output_schema]precisely up front, since the whole integration into[integration_target]depends on stable JSON. - Set
[summary_length]and[key_point_count]to what your report actually needs rather than padding them. - Use
[secondary_audio_type]to build a second template family; meetings and podcasts need different extraction logic. - Confirm
[max_duration]and supported[audio_formats]against your real files before wiring the pipeline. - Keep
[job_store]status tracking honest so failed chunks get retried instead of silently dropped. - Build the export step around
[export_formats]your team actually consumes, since a PDF report and a Markdown feed serve different downstream uses. - Validate diarization on a sample before trusting it network-wide; overlapping speech is where speaker labels tend to slip.
