AGENT SKILL

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

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

  1. 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.
  2. Agenda tease (10s) — Miles lays out what they'll cover, casually.
  3. 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.
  4. Rapid fire (45s) — alternating one-liners on the leftover items, quick tempo.
  5. 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: & → &amp;, < → &lt;, > → &gt;.
  • 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 with version="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: Nova rate="+6%" pitch="+2%", Miles rate="-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: chat for banter, friendly for explanation, narration-professional for the factual core of a story, excited sparingly 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 exceed 900ms.
  • 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:

  1. Confirm the ConverttexttospeechwithSSML tool is available on the agent. If it is not, tell the user how to add it and stop.
  2. Call ConverttexttospeechwithSSML with the SSML document from Step 9 and outputFormat: riff-24khz-16bit-mono-pcm.
  3. 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

microsoft
microsoft/cat-agent-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.

★ 105
microsoft
microsoft/cat-agent-skills

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.

★ 105
microsoft
microsoft/cat-agent-skills

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.

行政与办公人员文档处理演示文稿
★ 105
microsoft
microsoft/cat-agent-skills

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.

★ 105
microsoft
microsoft/cat-agent-skills

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.

文档处理
★ 105
microsoft
microsoft/cat-agent-skills

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.

★ 105