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.1 KiB
name, description, when_to_use, tags
| name | description | when_to_use | tags | ||
|---|---|---|---|---|---|
| mobile-platform-conventions | Where iOS and Android genuinely differ in expected behaviour, and where a shared design is fine. | You are designing a screen or flow that ships on both iOS and Android. |
|
Share the layout, respect the platform where it is muscle memory
Most of a design ports unchanged. A small number of behaviours are so deeply learned that violating them reads as a bug rather than a style.
The differences that actually matter
| iOS | Android | |
|---|---|---|
| Back | swipe from left edge; back button top-left | system back gesture/button — must work |
| Primary nav | tab bar, bottom | bottom nav bar (or drawer) |
| Destructive confirm | action sheet from bottom | dialog, centred |
| Text input done | "Done" / return key | often the system back dismisses |
| Sharing | share sheet | share intent |
System back is the one to get right. On Android, back must always do something sensible: close the sheet, pop the screen, and at the root, exit. A screen that traps back is broken in a way users will not report — they will just leave.
Safe areas are not optional
Notches, dynamic islands, home indicators and rounded corners all intrude. Anything within 16pt of an edge needs safe-area insets, not fixed padding. Test on a device with a notch and one without.
Touch targets
44pt minimum on iOS, 48dp on Android. This is the most frequently violated rule in dense interfaces and the most frequently reported as "the app feels unreliable" rather than as a size problem.
What NOT to differentiate
Content layout, spacing scale, typography hierarchy, colour and iconography can and should be shared. Building two visual designs doubles the work and the bugs for a difference users do not notice, and it is the usual reason a "platform conventions" pass runs over.
Test on the smallest supported device
Layouts are usually designed on a large phone and break on a small one, not the reverse. The smallest supported screen at the largest system font size is the worst case, and it takes one simulator run to check.