Use this skill whenever a warpdroid (Android client) change or bug needs to be verified by actually driving the app's visual UI — any task phrased as "test the warpdroid UI", "click through the screens", "does the button/compose/chat actually work on the device", "прокликать интерфейс", "проверь экран X на андроиде", "smoke-test warpdroid on an emulator", "take screenshots of the app", or when you've changed an Activity/Compose screen/adapter and want on-device confirmation rather than just a build. This skill MANDATES bringing up an Android emulator, installing the app, pairing it with a real Warpnet node, and driving it black-box via `adb`/`uiautomator` — that is the required verification vehicle. Do NOT use this skill to add a new protocol route (use `warpnet-add-handler`), to verify a node handler over `/ws` (use `warpnet-testnet-verify`), or to diagnose a cross-layer wire bug whose symptom you already have (use `warpnet-debug-stack`). Use it to confirm the Android UI itself behaves on a running device.
Use this skill whenever a Warpnet change needs to be verified by actually running it in the testnet network — any task phrased as "test this in testnet", "verify the feature works", "check it end-to-end", "does the handler actually respond", "prove the route works on a real node", "smoke-test before pushing", or when you've just added/changed a handler, DTO, or protocol path and want runtime confirmation rather than just `go test`. This skill MANDATES bringing up a real business node (`cmd/node/business`) on `--node.network=testnet` and driving it over its `/ws` bridge — that is the required verification vehicle, not an optional one. Do NOT use this skill to design a new handler (use `warpnet-add-handler`) or to diagnose a cross-layer bug whose symptom you already have (use `warpnet-debug-stack`). Use it to confirm a change is live and correct on an actual node.
Use this skill whenever the task is to add a new feature to Warpnet that crosses layers — anything described as a "new endpoint", "new route", "new RPC", "new event", "new path", or any feature that needs a frontend (Vue desktop or Android/Tusky) to talk to the local node and/or one node to talk to another. Triggers include phrases like "add /private/get/...", "add a handler for X", "expose Y to the UI", "make nodes exchange Z", "expose X to warpdroid", "add support for X in the Android client". Also use when the change is Android-only but touches a Warpnet protocol ID (new ProtocolIds entry, new DTO, new WarpnetRepository method). Do NOT use this skill for pure-Tusky-side UI changes that don't touch any Warpnet protocol, pure DB-schema changes that no one calls, or for fixing existing handlers without adding new routes.
Use this skill when an existing Warpnet feature behaves wrong end-to-end and the cause might span layers — symptoms reported on warpdroid or the Vue desktop UI ("notifications are empty / blank rows", "avatars don't load", "timeline freezes", "the connection keeps flapping every 30s", "context deadline exceeded", "Transaction Conflict. Please retry", "images don't appear", "replies show blank rows", "drawer shows @warpnet.local"), or about the cross-language wire contract ("DTO mismatch", "Moshi defaults to blank", "the test passed but the device shows empty"). Triggers include phrases like "fix the X bug on warpdroid", "X is broken on Android but works on desktop" / "works on desktop but broken on Android", "diagnose why this is failing", "the request never reaches the server", "the response parses to blanks". Do NOT use this skill to add a new route or feature — for that use [warpnet-add-handler]. Do NOT use this skill for pure-Tusky UI tweaks that don't cross the Warpnet boundary.