generating-podcast-script
Use this skill whenever the user asks to write, generate, or create a podcast script or podcast episode — from a topic, or from source material such as a news digest, newsletter, email review, or set of articles — and optionally convert it to audio with Azure Text-to-Speech. Handles the initial request and every follow-up refinement (source, topic, length, cast, narration) in the same task.
- License 许可
- MIT
- 最近更新
- 2026-11-13
- Stars
- ★ 105
- Forks
- 120
01 前言 Front Matter
- name
- generating-podcast-script
- description
- Use this skill whenever the user asks to write, generate, or create a podcast script or podcast episode — from a topic, or from source material such as a news digest, newsletter, email review, or set of articles — and optionally convert it to audio with Azure Text-to-Speech. Handles the initial request and every follow-up refinement (source, topic, length, cast, narration) in the same task.
02 资源文件 2
- 参考文档metadata.json539 B
- 参考文档README.md3.7 KB
03 SKILL.md 正文
Podcast Script Generation
Produces a two-host, NotebookLM-style conversational episode: a readable script plus a multi-voice SSML document ready for Azure Text-to-Speech.
Step 1 — Gather inputs
Ask only for what is missing. Do not ask for optional fields that have safe defaults.
| Input | Required | Default |
|---|---|---|
source or topic |
Yes | — (source material such as a digest/newsletter/articles, or a plain topic) |
duration |
No | medium — short ≈ 3 min / ~450 words, medium ≈ 6 min / ~900 words, long ≈ 12 min / ~1,800 words |
language |
No | English |
cast |
No | Two hosts, NOVA and MILES (see Step 4) |
generate_audio |
No | Ask after the script is ready |
All word targets assume ~150 spoken words per minute. Stay within 10 percent of target.
Derive a lowercase-hyphenated <slug> from the source or topic (max 6 words,
ASCII only).
Step 2 — Parse the source material
Skip this step when the user gave a bare topic with no source material.
Extract every distinct article or item. For each, capture:
- headline
- publication / source
- date, if present
- the core factual claim
- any figures or quotes
- the "so what"
Merge duplicates covering the same event. Discard boilerplate, footers, disclaimers, legal notices, unsubscribe text, and image captions.
Step 3 — Editorial selection
Rank items by newsworthiness and reader impact. Keep the top 4 to 6 for full
treatment (fewer for short, more for long). Group the remainder into one
fast rapid fire segment. If the material has a dominant theme, lead with it
and thread it through the episode.
Step 4 — Cast
Two hosts, always the same personalities, always distinct voices:
- NOVA — voice
en-US-AvaMultilingualNeural. Lead host. Warm, curious, quick. Drives the agenda, asks the question the listener is thinking, reacts out loud, reframes jargon into plain language. Slightly faster cadence. - MILES — voice
en-US-AndrewMultilingualNeural. Analyst. Calm, dry, precise. Supplies context, numbers, caveats, second-order implications. Slightly slower, lower pitch. Occasionally pushes back on Nova.
Neither host is a narrator. They talk to each other, not to the microphone.
Step 5 — Episode structure
- Cold open (15–20s) — Nova opens on the single most striking fact or tension. No "welcome to the podcast", no channel branding, no music cues.
- Agenda tease (10s) — Miles lays out what they'll cover, casually.
- Story segments (60–90s each) — one item per segment. Pattern: hook → the facts → why it matters → a short exchange of interpretation → handoff line into the next story. Vary who leads each segment.
- Rapid fire (45s) — alternating one-liners on the leftover items, quick tempo.
- Close (20–30s) — three concrete takeaways split between the two hosts, then a short human sign-off. Alternate whether Nova or Miles ends.
Step 6 — Dialogue style
This is what makes it sound conversational rather than read-aloud.
- Write spoken English, not written English. Contractions everywhere.
- Keep most lines under 30 words. Break long explanations across two or three turns with the other host interjecting.
- Use real conversational connective tissue — "okay so", "right", "wait, back up", "here's the part I didn't expect", "yeah, and that's the thing", "hmm". Roughly one marker every 4 to 5 turns. Never let it become a tic.
- One host regularly asks the naive clarifying question so the other can explain.
- Use one concrete analogy or comparison per complex item.
- Genuine reactions are allowed ("that number is wild"). Invented opinions on people, companies, or politics are not.
- Never read a headline verbatim. Paraphrase it into speech.
- Attribute clearly: "according to the Financial Times", "Reuters is reporting".
- If the source is ambiguous or a claim is unconfirmed, say so on air: "the report is careful to call that unconfirmed".
- No stage directions, no "[laughs]", no speaker labels, no markdown, no emojis, no bullet points, and no URLs in the spoken text.
Step 7 — TTS hygiene
Applies to every word that will be spoken.
- Spell out anything a synthesizer would mangle: "twenty twenty-six" not
2026, "three point two billion dollars" not$3.2B, "about fifteen percent" not~15%. - First mention of an acronym: expand it, then use the short form.
- Letter-by-letter acronyms:
<say-as interpret-as="characters">API</say-as>. - Odd proper nouns:
<sub alias="phonetic spelling">Name</sub>. - A non-English name or phrase inside an English line:
<lang xml:lang="fr-FR">...</lang>. - Escape XML entities in all spoken text:
&→&,<→<,>→>. - Never emit smart quotes, em dashes, asterisks, or underscores.
Step 8 — Write the readable script
Write the human-readable transcript to:
/app/created/<slug>_Podcast_Script.txt
This file — and only this file — may carry NOVA: / MILES: speaker labels so
a person can follow along. It contains no stage directions and no markdown. The
spoken text itself must already satisfy Steps 6 and 7 so it can be lifted into
SSML unchanged.
Step 9 — SSML output contract
Produce the SSML document and nothing else — no preamble, no explanation, no code fences, no trailing notes inside the artifact. Write it verbatim to:
/app/created/<slug>_Podcast.ssml
Rules:
- Exactly one root
<speak>element withversion="1.0",xmlns="http://www.w3.org/2001/10/synthesis",xmlns:mstts="http://www.w3.org/2001/mstts",xml:lang="en-US". - One
<voice>element per conversational turn. Alternate speakers. Never put both hosts inside one<voice>element. - Vary delivery with
<prosody>so it never sounds flat. Baselines: Novarate="+6%" pitch="+2%", Milesrate="-2%" pitch="-4%". Nudge per line to match the emotion of the sentence. - Use
<mstts:express-as style="...">where the voice supports it. Preferred styles:chatfor banter,friendlyfor explanation,narration-professionalfor the factual core of a story,excitedsparingly for the cold open. An unsupported style is ignored by the service, so keep styles optional — never structural. - Pauses:
<break time="250ms"/>between turns within a segment,<break time="700ms"/>between segments,<break time="400ms"/>before a punchline or a pivot. Never exceed900ms. - Every
<break>must sit inside a<voice>element. A<break>placed between<voice>elements — as a direct child of<speak>— is invalid in a multi-voice document and will fail synthesis. Two<voice>elements may sit directly next to each other with nothing between them. To pause between turns, put the break at the end of the preceding turn's text, inside that turn's<prosody>. <emphasis level="moderate">on at most one or two key terms per segment.- Keep the total document under 40,000 characters.
Shape
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:mstts="http://www.w3.org/2001/mstts"
xml:lang="en-US">
<voice name="en-US-AvaMultilingualNeural">
<mstts:express-as style="excited">
<prosody rate="+8%" pitch="+3%">Okay, so the number that stopped me cold
this morning was forty percent. <break time="300ms"/> Forty percent, in one
quarter. <break time="250ms"/></prosody>
</mstts:express-as>
</voice>
<voice name="en-US-AndrewMultilingualNeural">
<mstts:express-as style="chat">
<prosody rate="-2%" pitch="-4%">Right, and the part everyone's skipping is
that it's off a very small base. <break time="250ms"/> Context matters
here. <break time="700ms"/></prosody>
</mstts:express-as>
</voice>
</speak>
Note the trailing <break> closing each turn: the 250ms is the gap before the
next turn, the 700ms is the longer gap before the next segment. Nothing sits
between the two <voice> elements.
Step 10 — Review, then generate audio
Show the user a table summarising each segment (title, one-line description, approximate spoken duration), print both file paths, and ask:
Would you like me to convert this to an audio file?
Only if they say yes:
- Confirm the
ConverttexttospeechwithSSMLtool is available on the agent. If it is not, tell the user how to add it and stop. - Call
ConverttexttospeechwithSSMLwith the SSML document from Step 9 andoutputFormat: riff-24khz-16bit-mono-pcm. - Decode the base64 response and save to
/app/created/<slug>_Podcast.wav.
If the document is too large for a single call, split it at a segment boundary and synthesize each part separately.
When stitching, do NOT concatenate decoded RIFF/WAV bytes; instead, append the audio at the PCM-frame level (e.g., via Python’s wave module) and write a single valid /app/created/<slug>_Podcast.wav with one header.
import base64
with open('<tool_output_file>', 'r') as f:
content = f.read().strip()
audio_bytes = base64.b64decode(content)
with open('/app/created/<slug>_Podcast.wav', 'wb') as f:
f.write(audio_bytes)
Step 11 — Final report
Always end with:
| Item | Details |
|---|---|
| Script file | /app/created/<slug>_Podcast_Script.txt |
| SSML file | /app/created/<slug>_Podcast.ssml |
| Word count / estimated duration | actual vs. target at ~150 wpm |
| Items covered | full segments + rapid-fire count |
| Voices | en-US-AvaMultilingualNeural (Nova), en-US-AndrewMultilingualNeural (Miles) |
| Audio file | /app/created/<slug>_Podcast.wav (only if audio generated) |
04 同仓库更多 Skills
stakeholder-and-decision-map
Mines customer interactions to identify stakeholders, infer their likely roles and engagement, map the decision process, and highlight who or what may be missing. Use when asked to "map a deal's buying group", identify influential or missing stakeholders, "assess who has gone quiet", or "explain how the customer will decide". Do not use for phased engagement plans, contact sequences, choosing or drafting outreach to the single next contact, seller or team performance reviews, or contacting, scheduling, or changing records.
sales-progress-update
Creates or refreshes a sales progress update for a manager or team about work done, deal movement, pending outcomes, supported forecast position, and help needed. Use when asked to "create my weekly sales update", "refresh my sales progress deck", "report my forecast position", "where do I stand against my quarter forecast", or "catch my manager up on committed deals". Do NOT use for non-sales project updates, a since-date deal change digest, momentum or blocker analysis, meeting prep, or outreach drafting.
submission-assemble
Put the checked CSR or 510(k) sections together in template order with a reviewer-facing open-items register, as a draft package for human sign-off. Use when the user asks "assemble the CSR draft", "put the module together for review", "build the review package with the open items on top", "compile the 510(k) sections in order" or "package this up for the submission lead". Do NOT use for assembling an unchecked draft - use consistency-check instead. Do NOT use for loading protocol, SAP or TLF sources - use source-ingest instead. Do NOT use for compiling general documents or slide decks - use the built-in docx or pptx skill instead. Do NOT use for filing or submitting to a regulator - use the sponsor's validated gateway, operated by a human, instead. Guardrail: draft for human approval only (L1); status is draft_clean or draft_open_items, never submitted.
source-ingest
Pull every number, date and population definition out of a study's protocol, SAP, TLF tables, investigator brochure and prior approved text into one cited fact map, keyed per config/field-dictionary.json, before any CSR or 510(k) section is written. Use when the user asks "here's the locked TLF set and SAP, set up the CSR", "load the protocol and tables before we start drafting", "what figures do we have from the database lock?", "pull the disposition counts out of Table 14.1.1" or "ingest the IB for the 510(k)". Do NOT use for drafting or assembling submission sections - use section-draft or submission-assemble instead. Do NOT use for reconciling a patient's medications - use the discharge-care-transition plugin instead. Guardrail: reads and cites sources only; never estimates, rounds or invents a fact.
section-plan
Work out which sections a CSR or 510(k) requires, from the templates in config, check each one against the cited fact map, and name what is missing before a word is drafted. Use when the user asks "what do we still need before we can draft the CSR?", "which sections are ready to start?", "what's blocking the performance data section?", "do we have everything for the synopsis?" or "map our tables to the E3 structure". Do NOT use for writing section language - use section-draft instead. Do NOT use for cross-checking a finished draft - use consistency-check instead. Do NOT use for outlining general Word documents or business reports - use the built-in docx skill instead. Only structures with a template in config are supported. Guardrail: plans only; never marks a section ready on a missing fact and never invents a structure.
section-draft
Write or revise the language for one planned CSR or 510(k) section - synopsis, efficacy, safety, discussion, device description - using only figures already in the cited fact map, each with its TLF or SAP citation. Use when the user asks "draft the Synopsis from our locked tables", "write up safety from Table 14.3.1", "give me a first pass at the discussion", "draft the device description for the 510(k)" or "tighten the wording of the Discussion section". Do NOT use for supplying a number not already in source_facts - use source-ingest instead. Do NOT use for verifying a draft's figures - use consistency-check instead. Do NOT use for appeal letters, clinical notes or discharge summaries - use the matching HLS plugin instead. Guardrail: drafts for human approval only (L1); never asserts an unsourced number or harmonises two figures.