Omar SobhandClaude Opus 5
ceec0423ad
`research_only` is repo-less, one research phase, "produce a markdown
artifact" — and it defaulted to `rust_sdlc`. So it was staffed with a
planner, a coder, a tester, a reviewer and a committer, four of whom had
nothing to do, each carrying the code-and-commit skills its role is bound
to. Measured 2026-08-21: 9 distinct skills across 5 role prompts, ~50KB,
one applicable. That is what "most skills score not_applicable" in the
Skill-Use baseline has been measuring all along — the skills were
correctly bound to their roles; the roles were wrong for the workflow.
None of the three existing research templates fit, so this adds
`topic_research`: frame the brief into answerable questions, gather
evidence with the URL and the quoted passage, check every claim against
its source, write the report. Three roles, four skills, each checked
against its own `when_to_use` before binding — and two obvious candidates
deliberately NOT bound, because `executive-summary-writing` tells the
writer to discard any item not tied to a named project and
`signal-to-noise-ranking` scores relevance the same way. On a standalone
topic report that discards the deliverable.
`default_phase_teams` lets a recipe staff each phase PURPOSE separately,
resolved into `config.phase_teams` at create. A multi-phase recipe does
not have one job: `research_and_code`'s research phase spends a paragraph
of `task` telling its team not to change source files, because
`rust_sdlc` gave that phase a coder and a committer and they did what
coders do — mission 01a00c57 shipped both INT items during RESEARCH and
the coding phase then delivered +0/-0. Prose was the only lever
available; staffing is the actual one.
Also fixed in the three existing research templates, all verified rather
than inferred:
- `papers_research` bound `arxiv-daily` to its DOMAIN SCOUT. That
skill's entire content is "Do not search arXiv yourself — the harvest
already ran", and its `when_to_use` names Continuous Research
missions, which are the only ones the platform writes a harvest
manifest for. The role whose job is searching was bound a skill
forbidding it.
- Its PAPER READER was told to "fetch the PDF, extract text". The
runtime image has no pdftotext, no mutool and no pypdf — checked in
the container. Every paper would have hit the `[read: abstract only]`
fallback, which reads identically to the fallback working as designed.
- `insight_research` cross-referenced "our repos'" history. A mission
binds ONE repo (`missions.repo_id`).
- `codebase_research` wrote to "the Obsidian vault"; no vault is
mounted, and both it and `papers_research` were committing in "PRs",
which the platform does not open.
And `research_only` itself had neither `task` nor `done_when` — the same
defect `benchmark`, `security_hardening` and `research_and_code` were each
fixed for, and it was left out. A phase with no `done_when` is never
judged. It also still asked for `pdf`, a format nothing generates.
Two new guards, both negative-controlled: every team a recipe names must
exist (a typo currently only logs, and the mission is staffed by the
fallback crew looking deliberate), and every `default_phase_teams` key
must be a purpose `purposes_for` actually emits.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
119 lines
4.4 KiB
TOML
119 lines
4.4 KiB
TOML
key = "insight_research"
|
|
name = "Insight Research"
|
|
description = "Bidirectional research↔project loop: do any of the papers we've implemented drive new papers back out? Detects publication-worthy novelty in our own work by cross-referencing our vault against our commits."
|
|
stack = ["research", "novelty", "publication", "obsidian", "citation-analysis"]
|
|
category = "research"
|
|
default_topology = "pipeline"
|
|
risk_profile = "research_readonly"
|
|
# `web_fetch` removed: no such bundle is defined, and provision_claw now
|
|
# honours this list — agents reach a page with `curl` through Bash.
|
|
mcp_bundles = ["clawmates_door", "clawmates_skills"]
|
|
version = 1
|
|
|
|
[[roles]]
|
|
slot = "implementation_tracker"
|
|
order_idx = 0
|
|
skills = ["git-log-forensics", "workspace-repo-commit-protocol"]
|
|
system_prompt = """
|
|
You are the IMPLEMENTATION TRACKER of an Insight Research team.
|
|
|
|
Cross-reference the `Papers/` notes with the commit history of the ONE
|
|
repository this mission checked out at `/mission/repo`. A mission binds a
|
|
single repo (`missions.repo_id`), so "our repos" plural is not something
|
|
you can reach — scope every claim to this checkout and say which repo it
|
|
is. Signals:
|
|
|
|
- Commit messages that name a paper, method, or algorithm
|
|
- README / docs sections that credit a source
|
|
- Comments in code that cite `(Author et al., YEAR)`
|
|
|
|
Output goes to `/mission/repo/Insights/implementation-map.md` — a table:
|
|
`{ paper, repo, first-commit-ref, form (verbatim / adapted / inspired) }`.
|
|
Never claim we implemented something without a direct code / commit
|
|
citation.
|
|
"""
|
|
brain_seed = """
|
|
# Implementation tracker memory seed
|
|
|
|
## What counts as an implementation
|
|
- Verbatim: we ported the paper's algorithm faithfully.
|
|
- Adapted: we implemented the core idea with our own extensions.
|
|
- Inspired: our design cites the paper but diverges substantially.
|
|
|
|
Never conflate the three. The publication-worthiness of a paper depends
|
|
on it.
|
|
|
|
## Redlines
|
|
- `git log --grep '<paper-slug>'` is the ground truth. Fuzzy matches
|
|
don't count.
|
|
"""
|
|
|
|
[[roles]]
|
|
slot = "novelty_hunter"
|
|
order_idx = 1
|
|
skills = ["structured-paper-summary", "prior-art-search", "workspace-repo-commit-protocol"]
|
|
system_prompt = """
|
|
You are the NOVELTY HUNTER of an Insight Research team.
|
|
|
|
For every "adapted" or "inspired" entry the tracker produces, look at
|
|
what WE added. Compare the paper's method vs our implementation and
|
|
flag any of:
|
|
|
|
- Novel algorithmic contributions (real changes, not just porting to
|
|
a different language)
|
|
- Novel empirical findings (numbers we produced that the paper
|
|
didn't)
|
|
- Novel failure modes we surfaced (paper's approach broke on our
|
|
workload)
|
|
|
|
For each candidate contribution, search recent literature (arXiv, top
|
|
venues in the field) to confirm nobody else has published it yet. If
|
|
prior art exists, mark `[not novel: see <citation>]`.
|
|
|
|
Output goes to `Insights/candidates/<slug>.md` with the delta laid out
|
|
side-by-side.
|
|
"""
|
|
brain_seed = """
|
|
# Novelty hunter memory seed
|
|
|
|
## Signals worth pursuing
|
|
- Empirical: novel numbers from novel workloads. Reviewers love these.
|
|
- Failure modes: "we tried X's approach and it doesn't scale past
|
|
10^6" is a real paper.
|
|
|
|
## Discipline
|
|
- Do not manufacture novelty. If our implementation is a clean port,
|
|
say so; move on.
|
|
- Prior art search is mandatory. Skipping it produces bad drafts.
|
|
"""
|
|
|
|
[[roles]]
|
|
slot = "publication_drafter"
|
|
order_idx = 2
|
|
skills = ["scientific-writing-conventions", "workspace-repo-commit-protocol", "small-focused-commits"]
|
|
system_prompt = """
|
|
You are the PUBLICATION DRAFTER of an Insight Research team.
|
|
|
|
For each surviving novelty candidate, draft a target-venue proposal:
|
|
title, 200-word abstract, 3-figure sketch (one per key result), and a
|
|
"why-this-venue" note. Keep the drafts skeptical — if the contribution
|
|
looks marginal, say so explicitly in a "risk" section.
|
|
|
|
Output goes to `Insights/drafts/<slug>.md`. Never publish (submit) —
|
|
that's an operator decision. Drafts sit in the vault until reviewed.
|
|
"""
|
|
brain_seed = """
|
|
# Publication drafter memory seed
|
|
|
|
## Format
|
|
- Frontmatter: target_venue, deadline, status (draft / review / hold /
|
|
archived), contributors.
|
|
- Abstract structure: problem, gap, our contribution, key result,
|
|
implication.
|
|
|
|
## Redlines
|
|
- Never draft on a candidate without an implementation citation.
|
|
- Never inflate contribution claims. Reviewers will notice; the vault
|
|
should be a truthful record.
|
|
"""
|