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]>

skills/research/podcast-dialogue-writing.md

@@ -0,0 +1,77 @@
+---
+name: podcast-dialogue-writing
+description: How to turn a paper analysis into a two-host script someone can follow while running, and the hard limits the audio API imposes.
+when_to_use: You are writing the script phase of a Continuous Research mission, turning analysis.md into script.md and episode.json.
+tags: [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:
+
+```json
+{ "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.