run-interactive-session

Solid

Perform interactive testing on Kobiton devices using natural language. Translates user intents into CLI commands - WebDriver actions (find elements, type, click, swipe), device operations (adb shell, screen capture, port forwarding), file management (push/pull), app management, and test execution. Use when the user wants to interact with a mobile device on Kobiton, run exploratory tests, inspect device state, manage files on a device, or execute test sessions - even if they don't say "interactive test" explicitly. Trigger with "interact with kobiton device", "explore on kobiton", or "tap/swipe on device".

AI & Automation 12 stars 3 forks Updated today MIT

Install

View on GitHub

Quality Score: 78/100

Stars 20%
37
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Run Interactive Test ## Overview Drive a Kobiton device interactively from natural-language intent. Given a request like "find the Login button and tap it" or "pull the latest log file from this Pixel", this skill creates (or resumes) a session, translates the intent into the right CLI command - WebDriver action, `adb shell`, file transfer, app launch, test run - captures the response, saves artifacts (screenshots, page source) under the workspace, and reports back in plain language. Use this skill whenever the user wants to interact with a mobile device on Kobiton, run exploratory tests, inspect device state, manage files on a device, or execute test sessions - even if they don't say "interactive test" explicitly. ## Prerequisites Before invoking this skill, ensure: - **Bundled Kobiton CLI** - `~/.kobiton/bin/kobiton` (a symlink to this plugin's `run.sh` wrapper) must exist and point at an executable. Claude Code and Codex CLI both recreate it automatically via a bundled SessionStart hook; on Codex, the user trusts the hook once via `/hooks` after install. `/automate:setup` re-installs the symlink on demand on any host. GitHub Copilot CLI and Gemini CLI load `/automate:setup` (Copilot via Claude-format `.md`, Gemini via bundled TOML at `commands/automate/setup.toml`) but have no SessionStart hook - run `/automate:setup` once after install. The bundled binary targets **macOS** - on other platforms, do not invoke this skill; recommend `run-automation-suite` or the MCP ...

Details

Author
kobiton
Repository
kobiton/automate
Created
4 months ago
Last Updated
today
Language
JavaScript
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

run-automation-suite

Run local Appium test scripts against Kobiton devices. Guides through app upload, device selection, capability parsing, and local execution. Use when the user asks to run mobile tests, validate an APK or IPA on Kobiton devices, or kick off an Appium suite from a local script directory. Trigger with "run kobiton tests" or "execute appium on kobiton".

12 Updated today
kobiton
AI & Automation Solid

drive-automation-session

Drive an already-reserved Kobiton device from a natural-language intent. Opens an automation Appium session directly against the Kobiton WebDriver hub, runs an observe-decide-act loop with one action per iteration, pauses to ask the user when stuck (same-action repetition, screen unchanged, or model self-declared blocker), and returns the session id. Use when the user says "drive the device to X", describes a flow they want exercised on a reserved device, or asks to "automate this intent on Kobiton". Complements run-interactive-session (which uses the CLI session type) by using the automation session type so the resulting session is consumable by saveTestCase and the existing test-run authoring flow.

12 Updated today
kobiton
AI & Automation Solid

monitor-test-run

Watch a running Kobiton test run and narrate it to the user: read the org's live-remediation flag up front, poll the run until every execution is terminal, surface the live-remediation URL the moment an execution is blocked, and give a correct post-mortem so a COMPLETED-with-BLOCKER_ENCOUNTERED execution is never reported as passed. Quiet on passes, loud on blockers and the final summary; suite runs are grouped by test case. When live remediation is enabled, it asks up front whether to auto-open the live-remediation browser window when a blocker hits. Use when the user asks to "watch", "monitor", "track", or "follow" a test run, or as the natural follow-up right after createTestRun returns a testRunId. The watch runs a bundled poller that emits only on real state changes (no per-poll chatter); uses getOrgSettings up front and terminateTestRun on request, plus the shared chromeless launcher — it does not drive or resolve the blocker itself.

12 Updated today
kobiton