mobile-motion

This is the motion layer of the mobile app kit. It takes a reserved motion moment and makes it move well in code: easing, duration, springs, gestures, scroll, performance, accessibility. The default build surface is React Native / Expo, Reanimated-first; native SwiftUI is also supported (see references/swiftui-effects-catalog.md). SwiftUI additionally serves as the native-feel reference lens: even when emitting React Native, the SwiftUI spring-first mental model tells you how the motion should FEEL on iOS.

The gates (K1–K8), the spec process, and the cross-cutting laws (one-clock orchestration, choreography gates, the COMBO SPEC grammar, the expression budget) are surface-independent, owned once in references/effects-catalog.md. Pick the build surface, then read its catalog: React Native → effects-catalog.md + react-native-craft.md; native SwiftUI → swiftui-effects-catalog.md + swiftui-craft.md.

Where this sits in the kit

• mobile-design owns the static design and RESERVES where motion goes: the signature moment, the transitions, the gestures. It hands off a spec with those slots marked.
• mobile-motion (this skill) implements those slots and adds no new design taste. Same discipline as a craft layer everywhere: specs in, no taste out.
• The kit works standalone. It pairs with any plan → build → review workflow (for example the compound-engineering plugin's ce-plan / ce-work / ce-code-review): the build step runs the build; this skill implements motion to spec inside that build. It does not own the feature, the data, or the layout.

Stay in lane:

• Do not invent animated moments that are not in the spec or the request.
• Do not reorder or restyle screens. That is mobile-design's job.
• If no spec exists and the request is vague ("add some animations"), ask the four intake questions in IMPLEMENT instead of decorating every view.

Craft gates (K1 to K8)