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.2 KiB
name, description, when_to_use, tags
| name | description | when_to_use | tags | ||
|---|---|---|---|---|---|
| scientific-writing-conventions | Structure, hedging and claim discipline for a technical write-up that will be read by people who will check it. | You are drafting a paper, a technical report, or any document making empirical claims. |
|
Write so a sceptic can check you
The reader's question is "is this true?" Every convention below exists to let them answer it without asking you.
Structure
ABSTRACT problem, what you did, headline result WITH its number
INTRO why this matters, what was missing, contributions as a list
METHOD enough that a competent reader could reimplement it
RESULTS what happened, including what did not work
DISCUSSION what it means, what it does not, threats to validity
Contributions belong as an explicit list. If you cannot write three sentences each starting "we show that...", the work is not finished.
Hedge exactly as much as the evidence hedges
Both directions are failures. "Our method improves retrieval" from one dataset overclaims; "may potentially suggest a possible improvement" for a result with tight confidence intervals underclaims and reads as though you do not trust your own experiment.
Match the language to the strength:
- measured, with intervals, replicated → shows, demonstrates
- measured once, single configuration → indicates on X
- consistent with, not directly tested → is consistent with
Every number carries its conditions
A number without its dataset, configuration and variance is not a result. Put them in the sentence or the table, never in a paragraph three pages away.
Threats to validity is not a formality
State the ways you could be wrong: one seed, one hardware target, a benchmark your method was tuned on, a baseline you implemented yourself. A reviewer will find these; a paper that names them first is far more credible than one that lets them be discovered.
Say what you did not do
Scope limits are part of the contribution. "We do not evaluate on multilingual corpora" prevents a reader assuming you did and finding out later — which costs you far more credibility than the limitation itself.