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]>
2.3 KiB
2.3 KiB
name, description, when_to_use, tags
| name | description | when_to_use | tags | ||
|---|---|---|---|---|---|
| structured-paper-summary | Reading a paper for what it demonstrates rather than what it claims, and writing the summary in a fixed shape. | You are summarising a research paper for a digest, a brief, or a decision. |
|
Summarise the evidence, not the abstract
An abstract is the authors' pitch. The summary that is worth writing states what was actually demonstrated, on what, against what — and where those differ from the claim, that difference is the most valuable line in your summary.
The shape
CLAIM what the authors say they show, one sentence
METHOD what they actually did — the experiment, not the framing
EVIDENCE dataset, baselines, headline numbers, and what was NOT tested
STRENGTH strong / suggestive / anecdotal, with the reason
BEARING which of our problems this touches, or none
BEARING: none is a complete and useful entry. Most papers do not apply.
Read these four things first
- The baselines. A method that beats a weak baseline has shown almost nothing. Check whether the comparison is against the current standard or against a version of it the authors implemented.
- The dataset size and shape. A result on a million short web snippets may not survive on ten thousand long documents. Note the scale explicitly — it is the most common reason a transferable-looking result does not transfer.
- The ablations. A paper with no ablation has not shown which part of its contribution matters. If they claim four components and ablate none, treat the mechanism as unproven even if the number is real.
- What is missing. No error bars, one seed, one hardware configuration, no negative results — each weakens the claim, and none of them appear in the abstract.
Numbers with their conditions or not at all
"12% better recall" is unusable. "12% better recall at k=10 on SIFT1M against HNSW with M=16" can be checked, transferred or dismissed. If the conditions are not in the paper, that is itself the finding.
Say what would change your mind
The most useful line for a reader deciding whether to act: what result would make this wrong, and did the authors test it? A summary that a reader can act on tells them where the risk is, not just what the number was.