Use when controlling the Zepp OS app itself — requesting/querying runtime permissions, reading package info, detecting the scene (normal/AOD), accessing live workout/sport data, adding a text keyboard, or building a Workout Extension or media app.
Use when running Zepp OS code in the background or scheduling something for later - an app-service that runs independently of the foreground page (@zos/app-service, for tallying activity all day, etc.), waking the app at a wall-clock time or recurring schedule (@zos/alarm, "wake up at 8am every morning"), running a callback every N ms even when the screen is off (@zos/timer createSysTimer), posting a notification to the watch notification center (@zos/notification, "push a notification when the timer finishes"), or reacting to system events like sleep / shutdown / wake (app-event module). Use even when the wording is generic ("run later", "send a notification", "schedule a one-off task in 10 minutes", "run all day in the background") - this is the right skill for any deferred or background execution on the watch. Do not use for sending data from the phone side service to the watch (zepp-os-communication).
Use when improving the quality of a Zepp OS project itself rather than implementing a feature - debugging a Zepp OS app (there are no breakpoints, so logging strategy per runtime), catching otherwise-silent lifecycle errors (errors in onInit / build / onDestroy are swallowed with no source map), wrapping lifecycle hooks so a crash actually surfaces, structuring src/ for readability and unit testing, localizing strings via .po / gettext / i18n, or migrating a legacy 1.0 hm* / hmSensor / hmUI app to the modern @zos/* API. Use even when the question sounds like a generic JS / architecture / testing / i18n question if the context is Zepp OS. Do not use for the implementation itself of a feature - use the topic-specific skill (zepp-os-sensors for sensor reads, zepp-os-ui for widgets, etc.).
Use when sending data between a Zepp OS device app and its phone side service, making HTTP/fetch requests, downloading or transferring files to the watch, or talking to external BLE peripherals.
Use when handling watch-side hardware input or system info in a Zepp OS device app - reading physical buttons or digital crown, detecting wrist-raise / wrist-motion / gestures, showing a toast or a modal / confirm dialog, reading screen shape or device info, reading the user's system preferences (12h/24h time format, units, language, mode), loading i18n .po files, referencing asset image paths, or using EventBus / log / assets / px helpers and stringToBuffer / bufferToString (string ↔ ArrayBuffer). Use even when the task sounds generic ("show a confirm dialog", "read the language setting", "convert a string to a buffer") - Zepp OS has its own @zos/interaction, @zos/settings, @zos/device, @zos/i18n, @zos/utils APIs. Do not use for sensor / health data (zepp-os-sensors), page navigation (zepp-os-navigation-lifecycle), persistent storage (zepp-os-settings-storage), drawing UI widgets (zepp-os-ui), watchface rendering (zepp-os-watchface), or declaring permissions in app.json (zepp-os-fundamentals).
Use for Zepp OS project setup and structure decisions - editing app.json (manifest, permissions list, module entries, API_LEVEL, targets, designWidth, assets), deciding where code belongs (device app vs side service vs settings app vs app-service vs watchface module), supporting round + square device targets, scaffolding or laying out a new Mini Program or Watchface project, or explaining the four runtime contexts. Use whenever the question is "where does this code go", "what goes in app.json", "what permission do I declare in app.json", "how do I target this device", "how is a watchface project laid out vs a regular app", or "what's the difference between the device app and the side service". Do not use for runtime permission requests at execution time (zepp-os-app-control), for the implementation inside a specific module (use the topic skill), or for zeus CLI commands (zeus-cli).
Use when navigating between Zepp OS device-app pages, passing data between pages, wiring App()/Page() lifecycle hooks, launching or exiting the app, or controlling page scroll/swipe.
Use when the primary Zepp OS task is directly reading, subscribing to, configuring, or stopping @zos/sensor sensor/health data on a device app - heart rate, steps, calories, blood oxygen, accelerometer, gyroscope, GPS/geolocation, sleep, stress, battery, compass, workout, weather, wear/screen state. Use for permission details only when paired with implementing sensor reads. Do not use only because a query mentions sensor data if the task is persisting or aggregating values across app restarts, sending data to phone, displaying it in UI, declaring app.json permission strings, requesting permissions, scheduling background work, or building a watchface complication.