Omar SobhandClaude Opus 5
4358964c05
55 of 85 role skill bindings pointed at skills that were never authored,
so 10 of 11 team templates bound a smaller context bundle than their role
prompts assumed. Three roles bound nothing at all (gpu.bench_engineer,
threejs.shader_author, threejs.perf_engineer) while their prompts described
procedures they had no way to read.
The loader comment at team_template_loader.rs:167 already diagnosed this —
snake_case slugs in TOML against kebab-case skill files — and it was
half-fixed: the kebab names were corrected, the snake_case ones left.
It was invisible because both existing tests assert authored ⊆ referenced
(30/30, green) and the second explicitly declines to check the other
direction. So the failing half was the half nobody asserted.
Resolved every name by one of three explicit choices:
- 23 skills authored where the role genuinely needed the procedure
(gpu, threejs, research, analysis, frontend, mobile, backend, platform)
- renames onto authored skills where one existed in substance, including
the four-near-duplicate cases that collapse onto one real skill
- 22 aspirational references deleted — a binding an agent cannot read is
a promise, not a capability
Two tests now hold it. The unit test checks referenced ⊆ authored against
the files. The new integration test runs both loaders in boot order and
asserts the bindings survive the trip through the database, which is a
different question: resolution goes through skills_catalog rows, so a skill
file that exists but fails to ingest still leaves the role empty.
Negative controls: the unit test failed naming all 55; the integration test
fails naming the exact role when one name is reverted.
threejs.shader_author and .perf_engineer gained a second and third skill
after the collapse — pin_in_context pins idx < 2, so a role left with one
skill silently pins less than the policy intends.
Co-Authored-By: Claude Opus 5 <[email protected]>
48 lines
1.9 KiB
Markdown
48 lines
1.9 KiB
Markdown
---
|
|
name: prior-art-search
|
|
description: Establishing whether an idea is new, and finding the work that already did it before you build.
|
|
when_to_use: You are checking novelty before proposing or building something.
|
|
tags: [research, search]
|
|
---
|
|
|
|
# Assume it has been done, and go looking
|
|
|
|
The default hypothesis for any idea is that someone published it. Searching to
|
|
confirm novelty is a different activity from searching to find prior work, and
|
|
only the second one is honest.
|
|
|
|
## Search the mechanism, not your name for it
|
|
|
|
Your framing is unlikely to match the literature's. Decompose into the
|
|
mechanism and search that:
|
|
|
|
> "agent memory that remembers what it already read"
|
|
> → deduplication, seen-set, incremental corpus, novelty detection,
|
|
> continual retrieval
|
|
|
|
Three or four vocabularies, each searched separately. A single-phrase search
|
|
returning nothing is evidence about your phrasing, not about the field.
|
|
|
|
## Follow citations in both directions
|
|
|
|
- **Backwards**: the related-work section of the closest paper you find is a
|
|
curated survey someone else already did.
|
|
- **Forwards**: who cites it. This is where the field's response lives — a
|
|
strong result from two years ago that nobody cites was probably not
|
|
reproducible, and that is worth knowing before you build on it.
|
|
|
|
Two hops in each direction from one well-chosen paper covers a field faster than
|
|
any keyword sweep.
|
|
|
|
## The negative result is the deliverable
|
|
|
|
If the search finds it has been done, say so plainly and stop. That is a
|
|
successful search that saved the build. The failure mode is a search that
|
|
concludes "novel" because the searcher wanted to build it.
|
|
|
|
## Record the search, not just the conclusion
|
|
|
|
Which terms, which databases, which date range, and what was found. A novelty
|
|
claim without its search is unfalsifiable, and six months later nobody can tell
|
|
whether the field moved or the search was thin.
|