Omar SobhandClaude Opus 5
a2d7e3ea92
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.8 KiB
name, description, when_to_use, tags
| name | description | when_to_use | tags | ||
|---|---|---|---|---|---|
| paper-to-project-relevance | How to judge whether a paper actually bears on one of the operator's projects, and how to say so concretely instead of vaguely. | You are reading harvested papers in a Continuous Research mission and must decide which ones matter and why. |
|
Does this paper bear on our work?
The value of a research digest is not that it lists papers. It is that it tells you which of your problems just got easier. A summary that could have been written without knowing anything about the operator's projects has failed, no matter how accurate it is.
The test
For each paper, answer in this order. Stop at the first "no".
- Is the claim real? What did they actually measure, on what, against what baseline? A 40% speedup on a benchmark nobody runs is not a 40% speedup.
- Does it touch a problem we have? Not a problem in the same field — a problem in the project brief. "Vector search" is a field. "Our HNSW insert loop is serial and the ROADMAP flags it as needing a correctness pass" is a problem.
- Would we do anything differently? If the honest answer is "no, but it's interesting", say exactly that. It is a legitimate outcome and it costs the listener five seconds instead of two minutes.
Say the specific thing
Weak, and useless to act on:
This work on graph pruning could be relevant to vector search performance.
Strong, because it names the target and the change:
They prune by neighbour-degree rather than distance, which is the same decision
clawhdf5-ann/src/hnsw.rsmakes inprune_connections. Ours is already rayon-parallel per node, so this is a swap of the scoring function, not a restructure — maybe 30 lines. Worth trying because our ROADMAP lists recall regression at high M as an open question, and that is exactly what their Table 3 measures.
Name a file, a function, a roadmap item, or an open question. If you cannot name one, you have not established relevance — you have established topic overlap.
Honest negatives are the point
Most papers will not bear on the work. Recording that plainly is what makes the positives trustworthy. One line is enough:
No bearing — single-GPU training throughput, we do no training.
A run where everything is relevant is a run that stopped judging.
What NOT to do
- Do not infer relevance from keyword overlap. Sharing the word "agent" with our codebase is not a connection.
- Do not soften a negative into a maybe. "Could potentially inform future work" is how a digest becomes unreadable.
- Do not review from the title or the abstract's claims. The note carries
the abstract; the paper is one
curlaway. What a paper says it does and what its evaluation shows are routinely different, and catching that gap is most of the value you add.