what was measured
Evidence
A rule earns its place by changing what a model writes. These are the runs behind that claim, including the ones that changed nothing.
claude CLI · opencode 1.17.11harnesseshow to read this
Every skill here was measured. Drafted from a claim register, checked against primary sources, and run against control and treated arms on four model families. The documents below record what separated and what did not, including the results that went the other way.
The tasks are small on purpose. A self-contained task finishes in minutes and makes a difference attributable to one change. That is what makes it a measurement, and also what limits it: a real project has far more context competing for the model's attention and compounds a mistake across many files. A difference that shows as one run in a small task is larger in a real codebase, not smaller.
Results are per model tested. The same rule is unnecessary on one model and load-bearing on another, so nothing here is curated against the frontier alone. See the model matrix.
Headline findings
Capability is the variable. The same rule is unnecessary on one model and load-bearing on another, and the gap is large. Curating against the strongest model alone would have removed rules that two of the three models tested need.
Corpus support is an anti-signal. Register size has predicted result thinness across six axes. The largest register, 238 claims, produced the smallest skill, 3 rules.
Two skills measured as nulls. android/di separated on nothing across 24 runs. Its task tempted
every scope decision the skill makes and both models made the right call unaided.
Some rules the tested models already follow, and those are noted in each skill's evidence so a reader can judge what is worth installing for their model.
per skill
Jetpack Compose mechanics: what belongs in an effect rather than the composable body, how state is hoisted and remembered, and what makes a list recompose. Use when the UI is Compose.
14 rules · ~1,600 tokensAndroid architecture and platform decisions: where state lives, what survives process death, what work leaves the main thread, and what the platform can take away. Applies to any Android project, whatever the language or UI toolkit.
22 rules · ~2,600 tokensPersistence and offline behaviour: where a value lives, what survives, transactions, migrations, and what happens when the network does not answer. Use when the app stores data on the device.
15 rules · ~1,900 tokensThe object graph: what lives how long, what may depend on what, and when a wiring mistake is discovered. Use when the project uses Hilt, Dagger or Koin.
11 rules · ~1,500 tokensImages that arrive at runtime, fetched or picked or decoded: caching, sizing, cancellation, and what a picker actually hands back. Use when images are part of the product.
6 rules · ~1,300 tokensJava on Android without the language features Kotlin has: threading, equality, resource handling, and interoperating with Kotlin. Use for a Java codebase or the Java half of a mixed one.
16 rules · ~2,200 tokensKotlin mechanics on Android: coroutine scope and cancellation, flow collection, nullability and equality. Use when most of the code is Kotlin.
6 rules · ~1,000 tokensThe shape of the layer graph: which layers exist, which way dependencies point, and what each one may touch. Use when the app has a ViewModel layer.
7 rules · ~1,100 tokensTalking to a server: client configuration, what comes back, what happens when it does not, and how a request is authorised. Use when the app makes HTTP calls.
15 rules · ~1,800 tokensRuntime permissions: whether to ask at all, how to ask, and what the app does with every answer including the silent ones. Use when the app touches the camera, location, microphone, files or notifications.
8 rules · ~1,600 tokensKeeping a secret on a device you do not control: key storage, backup, intents, and client-side checks that are signals rather than controls. Use when the app holds a credential or talks to a server.
9 rules · ~1,700 tokensWhat makes a test able to fail for the right reason: the shape of the seam, the scheduler it runs on, and what an assertion is allowed to know. Use when writing tests, or changing code to make one possible.
3 rules · ~700 tokensThe View system: layouts, adapters, RecyclerView, ViewBinding, and the seam where a ComposeView sits inside a View hierarchy. Use when the UI is XML layouts.
14 rules · ~1,400 tokensmodel matrix
The same task across models, harnesses and providers.
Skills here are written for whatever model a project uses. Three things were varied deliberately to check that the results are not an artifact of one setup.
Models
Opus 5, Sonnet 5, Haiku 4.5 and qwen3.7-max, on the same task with the same prompts and the same isolated settings.
Capability is the variable, and it moves in one direction. The strongest model tested satisfies almost everything unaided. The mid-tier model drops a few. The smallest drops most of them. The rules did not change; the model did.
The skill closes the gap it was written for, and only below the frontier. Nearly everything the smaller models miss unaided is handled once the skill is loaded, and on the strongest model most rules make no difference because it already does them.
Two rules mark the two ends of that window. One is satisfied unaided by the strongest model and missed by both others, which is the rule a frontier-only evaluation would have deleted. Another is the reverse: it only improves on the strongest model, because a smaller one cannot act on it even when told.
That is why nothing here is curated against one model.
Harnesses
The same model, anthropic/claude-haiku-4.5, run through both the claude CLI and opencode
1.17.11, with the served model confirmed on both arms. Running a different model in a different
harness moves two variables at once and measures neither.
The largest effects survive the harness change. The two rules with the clearest improvement reproduce exactly. Smaller effects do not, and two of them move the other way.
That is the honest reading: a large effect is portable, and a marginal one is not evidence of anything outside the harness it was measured in.
Providers
Anthropic directly, and both the same and different models through OpenRouter, including
qwen3.7-max on a non-Anthropic model in a non-Claude harness.
That last run is a smoke test rather than a measurement, at one run per arm. What it establishes is narrow and worth having: several rules improved on a model from a different family entirely, so the skills are not shaped to one vendor's model or one vendor's tooling.