run-automation-suite

Solid

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".

AI & Automation 12 stars 3 forks Updated today MIT

Install

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 Automation Suite ## Overview Execute Appium-based mobile test automation suites on Kobiton's device cloud. Given a local Appium test script, this skill identifies the target app, selects an available device, parses and reconciles capabilities, runs the script in the background, and surfaces the resulting session URL plus artifacts (video, logs, screenshots, reports). Use this skill when the user asks to run mobile tests, validate an APK or IPA across real devices, or trigger a Kobiton-hosted automation run from a local script directory. ## Prerequisites Before invoking this skill, ensure: - **Kobiton MCP connection** - the Kobiton MCP server is reachable (default `api.kobiton.com/mcp`; check `.mcp.json` for the configured endpoint). - **Local Appium test script** - a runnable Appium WebDriver script (`.js`, `.ts`, `.py`, `.java`, `.kt`, `.cs`, `.rb`) referencing desired capabilities for the target platform. - **Runtime installed locally** - Node.js + npm/npx, Python + pip, Java + mvn/gradle, .NET SDK, or Ruby + bundle, whichever your test script uses. - **App build (or store reference)** - either a local `.apk` / `.ipa` / `.zip` build artifact for upload, or a `kobiton-store:vXXXXX` reference for an existing upload. - **Kobiton account** - credentials with device access for the target platform (Android / iOS) and remaining session quota. ## Authentication This skill calls tools served by the Kobiton MCP server at `api.kobiton.com/mcp`. Two authentication configu...

Details

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

Integrates with

Model Context Protocol · AI

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

run-interactive-session

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".

12 Updated today

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

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