Files
clawmates/skills/research/podcast-dialogue-writing.md
T
Omar SobhandClaude Opus 5 a2d7e3ea92
deploy / test (push) Successful in 4m4s
deploy / build (push) Successful in 1m45s
feat(skills): author the Continuous Research skills, and make its roles honest
The boot log has said `continuous_research — 4 role skills bound, 8 unresolved`
on every start. Those eight roles ran without the instructions their template
promised them, silently: `skills_loader` reports the miss and carries on.

Worse than the missing files was what the prompts described. v1 told the
harvester to sweep "RSS feeds, GitHub trending, HN front page, YouTube /
podcast RSS" — none of which exist. `harvest.rs` searches arXiv and nothing
else. A role prompt describing a machine that was never built is the failure
this codebase keeps paying for, so v2 describes the machine that exists.

Roles now match the pipeline: paper_reader (the harvest already ran; read the
manifest and the papers), signal_ranker (unchanged in spirit), script_writer
(the podcast half, which had no role at all).

Seven skills authored under skills/research/, kebab-case to match the loader —
team_template_loader.rs:177-181 documents the snake_case/kebab-case trap that
already unbinds skills elsewhere:

  arxiv-daily                  what the harvest guarantees, so an agent does
                               NOT re-search arXiv and corrupt the seen-set
  paper-to-project-relevance   name a file or roadmap item, or say "no bearing"
  duplicate-detection          the seen-set catches identity; this catches the
                               same work under a different id
  signal-to-noise-ranking      novelty/relevance/depth, and the two biases to
                               resist (recency up, inconvenience down)
  executive-summary-writing    what it is / why it matters / what to do — decide,
                               do not hedge
  obsidian-vault-conventions   the vault is a human's live workspace; never
                               main, never reorganise, hash the body not the file
  podcast-dialogue-writing     write for someone on a treadmill; the 10-70 char
                               highlight bound is the API's, not a style rule

`web_fetch` dropped from mcp_bundles: runtime_provision.rs binds every mission
claw to `["clawmates_door"]` and never reads that field, so declaring it
instructed roles to use a tool that never arrived. The prompts say `curl` via
Bash, which is what they actually have.

Boot now reports `continuous_research — 11 role skills bound`, with no
unresolved clause. 344 tests pass.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-17 14:44:03 -07:00

2.9 KiB
Raw Blame History

name, description, when_to_use, tags
name description when_to_use tags
podcast-dialogue-writing How to turn a paper analysis into a two-host script someone can follow while running, and the hard limits the audio API imposes. You are writing the script phase of a Continuous Research mission, turning analysis.md into script.md and episode.json.
research
writing

Writing for someone on a treadmill

The listener is not at a desk. They cannot scroll back, they cannot see a table, and they are half-listening. Everything follows from that.

Structure

Lead with the conclusion, then support it. A paper-by-paper walk is the wrong shape: the listener does not know which papers matter until you tell them, and by then the first one is gone.

COLD OPEN   one sentence: the single thing that changed today
THE MAIN    the paper that actually matters, 3-4 minutes
THE REST    two or three, a minute each
NOTHING     what you looked at and dismissed, 20 seconds

"Nothing" is not filler. Knowing that eleven papers were read and eight did not matter is what makes the three that did credible.

Two hosts, with a reason to be two

HOST carries the thread and asks what the listener would ask. GUEST has read the paper and answers. The reason for a second voice is that disagreement and "wait, why?" are easier to follow than monologue — not that alternating names looks like a script.

Bad, because these are one voice cut in half:

HOST: The paper introduces a new pruning method. GUEST: Yes, and it improves recall by 12%.

Good, because the second voice is doing work:

HOST: Twelve percent recall — is that on a benchmark we'd care about? GUEST: That's the catch. It's on SIFT1M, which is a million 128-dim vectors. Our embeddings are 1536-dim and we're at about 40,000. So the shape of their win might not survive at our dimensionality.

Say numbers the ear can hold

"Roughly a third faster" beats "34.7% faster". "About a million vectors" beats "1,000,000". Read every line aloud in your head; if you stumble, the TTS will too.

Never write anything the listener cannot hold: no URLs, no arXiv ids, no table references, no "as shown in Figure 4". If they need the citation it is in the vault note.

Hard limits, not style preferences

episode.json is consumed by the audio API, and these bounds are enforced by it:

{ "title": "<one line, under 80 characters>",
  "highlights": ["<each 10-70 characters>", "..."] }
  • At most 5 highlights, each 1070 characters. Outside that range the request is rejected, not truncated.
  • Target seven minutes of speech, roughly 1,000 words. Audio quality degrades on long single generations, so a sprawling script produces a worse episode, not just a longer one.

Cut rather than pad

If only one paper mattered, write a four-minute episode about one paper. An episode padded to length with work that did not matter trains the listener to skip, and once they skip, the whole pipeline is worthless.