fix(skills): every team-template skill binding now resolves
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]>
This commit is contained in:
co-authored by
Claude Opus 5
parent
ba98c29481
commit
4358964c05
@@ -0,0 +1,54 @@
|
||||
---
|
||||
name: scientific-writing-conventions
|
||||
description: Structure, hedging and claim discipline for a technical write-up that will be read by people who will check it.
|
||||
when_to_use: You are drafting a paper, a technical report, or any document making empirical claims.
|
||||
tags: [research, writing]
|
||||
---
|
||||
|
||||
# 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.
|
||||
Reference in New Issue
Block a user