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]>
2.9 KiB
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. |
|
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 10–70 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.