Riverside Editor to Podcast Content Pack

Skill Preview

---
name: pod-pack
description: >-
  End-to-end podcast episode production, built around Riverside's browser-based transcript editor.
  Drives Riverside in Chrome to make transcript-based cuts (delete text = delete audio+video), then
  turns the episode into a full publish-ready content pack — YouTube title, description and tags;
  Spotify description; a blog post; and social posts for LinkedIn, Instagram, TikTok, and a YouTube
  community post — plus corrected captions. Use whenever the user is producing a podcast episode:
  "edit in Riverside", "the podcast", "the episode", "show notes", "captions"/"SRT", "descriptions",
  or names a guest — even for just one deliverable. Content pieces are produced by spawning
  background agents in parallel. All show-specific facts (name, host, links, voice, repo) live in a
  show profile YAML, so the skill works for any show.
allowed-tools: Read, Write, Edit, Grep, Bash, Task
---

# pod-pack — podcast episode production

pod-pack turns a raw recorded episode into a finished, publish-ready package: corrected captions,
optional edit, and every piece of copy the episode needs across platforms — all in the show's own
voice. The edit phase is built for browser-based editors: it drives Riverside's web transcript
editor through Chrome.

**Everything show-specific lives in one place: the show profile.** Keep a short `show-profile.yaml`
with the show name, host, guest link fields, voice/copy rules, standard links blocks, and which
deliverables are enabled. Read it first, every time. If the user hasn't made one yet, gather those
facts interactively before producing copy, so nothing brand-specific is guessed.

The work splits into four phases. Phase 1 (editing) usually needs the user driving Riverside;
phases 2–4 you can largely drive yourself. You don't have to do all four — people often come back
for "just the descriptions" or "just fix the SRT". Do what's asked, skip the rest.

## Phase 1 — Edit the episode in Riverside (optional, browser-driven)

Riverside's editor is **transcript-driven, canvas-rendered**: you edit by selecting words in the
transcript, and deleting text removes the matching audio+video and shortens the timeline. The
transcript is drawn on a canvas, so it is NOT machine-readable via page-text / the accessibility
tree — you work by screenshots + coordinates, with the reliability tricks below.

**Setup.** Confirm the user is logged in (you can't log in for them) and has the correct **episode
edit** open — a recording can have several edits/versions, so verify the one on screen is right
before cutting. Load the Chrome tools with one ToolSearch call, `tabs_context_mcp` first.

**Find a spot with the transcript Search box.** Get the search input by **element reference**, not
pixel coordinates (`find` "search transcriptions", click the returned ref). Pixel clicks drift after
any window resize and silently miss — which sends keystrokes into the editor as shortcuts (space =
play/pause) and starts playback. Click the field by ref, then type. Short, unique anchor phrases
work best; to search again, click the field by ref, `cmd+a`, retype.

**Make a cut.** Riverside's auto "Remove Pauses"/"Remove Filler" leave invisible cut-gaps between
words. If a selection endpoint lands on a gap (or a `~` marker or the little dropdown arrow after a
sentence), a floating **"Refine cut / Restore"** popup appears instead of a clean delete. Land both
endpoints ON WORDS:
1. Click the **start** on the first letter of the first word to delete.
2. Scroll if needed, then **shift-click** the **end** on the *next word you're keeping* (cursor lands just before it) — this swallows the trailing pause and never hits a gap.
3. **Zoom-verify** before deleting: zoom on the selection and confirm the highlight covers exactly what you intend (kept words on both sides NOT highlighted).
4. Delete via the **trash icon in the bottom toolbar** (appears on a valid selection). Undo is top-left.

Gotchas: a shift-click near the **bottom edge** auto-scrolls the panel, so keep endpoints mid-panel
and re-verify after any scroll. If the selection doesn't take (no highlight, no trash button), you
hit a gap — Escape and re-select on words. After deleting, the cut shows struck-through and duration
drops; confirm the join reads cleanly (search the kept words around the cut). Window resizes shift
the coordinate mapping — take a fresh screenshot before any precise click.

**Black-preview red herring.** The preview may show black at a scrubbed position after heavy edits —
usually a stale preview proxy, not lost footage. Scrub to an early timestamp you know had video; if
only the tail is black, or the black also appears in an untouched edit of the same recording, it's a
**source recording dropout** (bandwidth drop at record time), not your edit. Export renders from
source, not the proxy, so a proxy-only glitch disappears on export. Transcript-text cuts cannot blank
video while keeping audio inside a single scene — the two issues are unrelated; reassure the user.

**What to cut, in priority order:**
1. **What the user flags** — always their call first.
2. **Dead-end tangents** — a topic that wanders and resolves in "anyway / it's something else". Cut the detour, keep a clean join.
3. **Credibility-denting asides** — host or guest undercutting themselves.
4. **Production artifacts** — "and now I'll stop the recording", meta outros. End on a real closing line.
5. **Legal/reputation risk** — a named-company accusation stated as fact. Do NOT auto-cut substantive discussion; surface it, let the user decide.
6. **Filler / long stutters** — the auto Remove Pauses/Filler handle most; only hand-cut an egregious stutter, and warn it's a fiddly sub-word edit.

**Don't do these for the user:** clicking **Export** (it's billed and their decision — guide them,
let them click and download the SRT) or publishing anywhere. Confirm each non-obvious cut, lean on
Undo, and log each cut as `search-anchor → keep … / delete … / keep …` so it can be replayed if the
episode is ever re-uploaded.

## Phase 2 — Fix the caption/SRT file

The user downloads the `.srt` from Riverside (usually into `~/Downloads`). Auto-transcription is
good on plain speech but reliably wrong on:
- **Names** — guests, founders, prior guests (a surname often mangled several ways in one file).
- **Brands / products** — company and app names, mangled inconsistently.
- **Domain jargon** — acronyms and terms (e.g. "CBT" → "C V G", "RAG" → "RAC", "Llama on AWS" → "Lama on NWS").
- It also inserts `~` hesitation markers throughout, which should not appear in captions.

Workflow:
1. **Read** the SRT and `grep -in` suspected tokens to see every occurrence and count.
2. **Build a replacement map** of exact phrases you're confident about (a recurring mis-hear that appears many ways still maps to the one correct spelling).
3. **Only correct what you're sure of.** For an uncertain brand or person spelling, LEAVE the transcription's version and flag it — a wrong-but-confident brand name is worse than an obvious mis-hear the user can fix in one grep.
4. **Apply the fixes directly:** strip every `~`, then apply the map, **preserving all cue numbers and timestamps**. Match with flexible whitespace so a correction lands even when the phrase falls across two caption lines within one cue. Write out `<name>-corrected.srt`. (A short Python/sed pass over the cue text does this; never touch the timestamp lines.)
5. **Verify:** grep the output — each fix landed, no `~` remain, no raw error tokens survive. Report the change list and the flagged uncertainties.

Example replacement map (exact phrase → correction; `__word_boundary__` applies `\bWORD\b` for short
tokens that must not match inside other words):
```json
{
  "C V G therapy": "CBT therapy",
  "Lama on NWS": "Llama on AWS",
  "<misheard surname>": "<correct surname>",
  "__word_boundary__": { "LV": "Elvie" }
}
Keep the final map in the episode notes so a re-upload can be re-corrected fast. The corrected SRT is
also the source of truth for timestamps — chapter markers come from where topics shift in it.

Phase 3 — Produce the content pack (spawn agents in parallel)

The heart of the skill. Once the SRT is clean, gather the episode facts once, then fan out.

Gather first (do this yourself, once):
- Guest: full name (verify spelling), role/title, org, and links (LinkedIn, site, org site).
- Episode number, host (from the show profile), runtime.
- 4–6 topic themes, 1–2 short accurate quotes from the corrected transcript, and the timestamp list.
- Keyword targets: 1 primary search phrase + 2–4 secondary phrases (guest, org, topics). These anchor SEO/AEO/GEO across every deliverable (see the optimization section below).

Then spawn one background agent per enabled deliverable, in the same turn, so they run in
parallel. Use subagent_type: "fork" — forks inherit this conversation's context, so they already
know the episode, the show profile, and the house style. In each agent's prompt: state the
deliverable, paste that deliverable's format (below), give the show-profile facts + links + keyword
targets, and require it to (a) match the show voice exactly, (b) never invent facts/quotes, (c)
report character counts where limits apply, and (d) optimize for SEO/AEO/GEO — front-loaded keywords,
question-shaped headings + FAQ on the blog, citable entity-rich phrasing, without keyword-stuffing or
bait.

Placeholders below: <SHOW>, <SHOW_PROSE>, <HOST>, <N> (episode number), <GUEST>, <ROLE>,
<ORG>, <GUEST_LINKEDIN>, <GUEST_SITE>, <ORG_SITE>, <EPISODE_URL>, and the links: blocks —
all from the show profile.

Deliverables (skip any turned off in the profile's deliverables: block):

1. YouTube title options — [topic-forward hook] | <SHOW> | <Ep. N>, ≤100 chars (count it; the tail eats into it). Topic-forward (guest usually NOT in the title), curiosity-driven but honest. To name a guest's org, fold it into an organic clause ([hook], Plus <ORG>), never a bare | <ORG> | slot (reads like the channel). Offer 4–6 options, mark a lead pick, note each character count.

2. YouTube description — house template:
#Tag1 #Tag2 #Tag3

In this episode of <SHOW>, <HOST> speaks with <GUEST>, <ROLE> and <ORG>, about <one-line framing>.

<3–5 short paragraphs walking the episode's arc, third person>

This episode is for <audiences>.

⏱️ Timestamps
<mm:ss lines from the corrected SRT>

📌 Links mentioned in the episode
<GUEST> on LinkedIn — <GUEST_LINKEDIN>
<GUEST>'s website — <GUEST_SITE>
<ORG> — <ORG_SITE>

🎙️ Connect with <SHOW>
<one line per links.show entry>

🎙️ Connect with <HOST>
<one line per links.host entry>

🎧 Listen
<one line per links.listen entry>

💬 Question
<one engagement question tied to the episode>

<show.disclaimer, if set>

3. YouTube tags — comma-separated plain phrases (no hashtags), ≤500 chars total (count it). Highest-value first (topic terms, guest, org, show, host, broad discovery), so a trailing trim stays safe. ~20–27 tags typical.

4. Spotify description (HTML) — Spotify renders only <p> <strong> <em> <ol> <ul> <li> <a> <br>; everything else is stripped. No hashtags, no emojis, no timestamps. Links use the full URL as anchor text with rel="ugc noopener noreferrer" target="_blank". Structure: intro <p> paragraphs → <p><strong>Connect with <GUEST></strong>…</p> → <p><strong>Connect with <SHOW></strong>…</p> → <p><strong>Connect with <HOST></strong>…</p> → <p><strong>Question for listeners:</strong><br />…</p> → <p><em> disclaimer </em></p> (if set).

5. Blog post (Markdown + frontmatter) — companion article for the show's site. If the site has its own content schema, read one existing post and match it; otherwise:
---
title: "<Descriptive title> | <SHOW_PROSE> | <Ep. N>"
description: "<one SEO-friendly sentence, ~150 chars>"
date: <YYYY-MM-DD>
author: "<HOST>"
readTime: "<X> min"
cover: "<image path — flag that the image needs to be created>"
---
Body — third person, editorial brand voice: open by introducing the episode + guest with an inline link and their org; embed the video after the intro; a ### In this episode, we cover: bulleted list; a few short ### highlight sections with 2–3 question-shaped headings answered immediately in a tight 40–60 word paragraph; a ### FAQ near the end (3–5 real questions with standalone answers); close with a listen CTA + connect-with-guest. Apply the SEO/AEO/GEO section throughout. 1–2 verbatim, accurate transcript quotes max. Keep named-company accusations general ("some apps in this space") — written posts carry more legal exposure than the spoken episode; flag if the user wants the name in.

6. LinkedIn post — match the host's real posts if you have one. Default shape: (1) hook — one curiosity question on its own line; (2) framing — In episode <N> of <SHOW_PROSE>, <HOST> sat down with <GUEST>, <2–4 credentials the way the host stacks them: role at org, notable past work, one concrete proof point>.; (3) They got into: then exactly 4 • bullets — specific, concrete takeaways, one idea each; (4) CTA — You can find the full episode wherever you get your podcasts, or listen here: <EPISODE_URL>. Below a ---: a posting note (@-tag prompts for guest + org) and one alternative hook. Shape to match tone:

▎ What does it actually take to build health tech that people trust?
▎
▎ In episode <N> of <SHOW_PROSE>, <HOST> sat down with <GUEST>, <ROLE> at <ORG>, <one notable past role>, behind <concrete proof point, e.g. 75+ products over 15 years>.
▎
▎ They got into:
▎ • <specific takeaway>
▎ • <specific takeaway>
▎ • <specific takeaway>
▎ • <specific takeaway>
▎
▎ You can find the full episode wherever you get your podcasts, or listen here: <EPISODE_URL>

7. Instagram caption — same shape as LinkedIn in a warmer voice (present tense, a light emoji fine). IG links aren't clickable → CTA "Full episode on YouTube and Spotify, link in bio". 5–10 hashtags at the end; @-tag prompt for the guest.

8. TikTok caption — reel-agnostic: must make sense over ANY clip, so frame the episode/theme, not one moment (avoid "in this clip…"). Short (≤150 chars before hashtags). Hook + CTA + 3–5 hashtags.

9. YouTube community post — short text post announcing the drop. 1–3 sentences, warm and conversational, one hook + one question, a "new episode out now" nudge. Self-contained (link added when posting).

10. Newsletter blurb — ≈60–120 words promoting the episode: one hook, one line on what listeners get, a clear "listen here" CTA with <EPISODE_URL>. Optional 3–5 word subject-line suggestion.

11. Pull-quote / graphic text — 2–3 short punchy lines for quote cards. Prefer verbatim guest lines; light tightening OK but keep accurate and attributable. Each ≤ ~120 chars. Note who said it.

Timestamps — derive from the corrected SRT: mm:ss Label per line, starting 00:00 Intro. Feed the YouTube description; can seed chapters.

Framing rules (apply to ALL social posts + the blog): never frame the guest as unqualified — an unconventional background is a credible strength, never a deficiency; lead with what they built and know. Use • bullets, not →. Honor the profile's voice.copy_rules everywhere (e.g. no em dashes, no ALL-CAPS if set).

Optimizing for SEO, AEO, and GEO

Apply to every text deliverable (blog, YouTube, Spotify, and lightly the social posts). SEO = search
ranking; AEO = being the answer in featured snippets / "People also ask"; GEO = being cited by
generative engines (ChatGPT, Perplexity, AI Overviews).

- Keyword work first (once): pick 1 primary phrase (natural language, what someone would search) + 2–4 secondary phrases (guest + org, key topics, named entities). Put the primary phrase in the title, the first ~100 words, one H2, the slug, and the meta/excerpt.
- SEO: front-load the primary phrase; descriptive keyworded slug (<show-slug>-ep<N>-<primary-topic-slug>); real skimmable headings; YouTube chapters + keyword-rich first two lines + tag variants; internal links (episode hub, 1–2 related posts, a show page) + external links to guest/sources; descriptive alt text on the cover.
- AEO: question-shaped headings answered immediately in a 40–60 word liftable paragraph; a short TL;DR/key-takeaways; an FAQ (3–5 Q&A) — highest-leverage move, powers FAQ schema; prefer lists and short definitional sentences for answerable bits.
- GEO: concrete, attributable statements — name entities fully, state facts plainly, attribute quotes; a 1–2 sentence extractable thesis high on the page; consistent entity naming across all surfaces so engines resolve the same entity.
- Structured data (blog): the published post should emit PodcastEpisode/VideoObject, Article/BlogPosting, and FAQPage JSON-LD. If the site layout already injects it, just ensure the frontmatter fields are present; otherwise flag it — don't hand-inline fragile JSON-LD unless that's the site's pattern.
- Guardrail: optimization never overrides accuracy or voice. No keyword stuffing, no invented stats, no engagement-bait questions the episode doesn't answer.

Assemble timestamps and the title shortlist on the main thread while agents run. Collect results as
they return, then close the loop with the user: confirm the title choice, any uncertain
guest/brand spellings, and any legal flag from phase 1. Keep everything in the show's voice.

Phase 4 — File the pack

Keep the pack per-episode (one folder per episode) so past episodes are easy to reference and diff.
Typical files: README.md (index + episode facts + open items), titles.md,
youtube-description.md, spotify-description.md, tags.md, timestamps.md, linkedin-post.md,
instagram-post.md, tiktok-post.md, youtube-community-post.md, newsletter.md,
pull-quotes.md, blog-post.md, captions.srt. If committing to a repo, use the author name/email
from the profile and non-interactive git; open a PR only if asked.

Guardrails

- Honesty over polish. Report cuts, flag what you couldn't verify, and never fabricate a quote or a brand name. A flagged uncertainty is a feature, not a failure.
- The user's episode, the user's calls. Confirm non-obvious cuts, the final title, and anything with legal/reputation weight.
- Don't do the irreversible/billed steps for them without asking: exporting from Riverside, publishing/posting, opening PRs.