verikun

$ vk ui
[0] TextView "Welcome back" (540,360)
[1] EditText @email_input (540,720) focused
[2] EditText @password_input (540,860) pwd
[3] Button "Sign in" @sign_in_btn (540,1020) tap
[4] TextView "Forgot password?" @forgot (540,1140) tap

$ vk tap @sign_in_btn
tapped [3] Button "Sign in" @sign_in_btn (540,1020) tap

What it is

verikun (CLI binaries verikun and vk) drives a connected Android device or emulator, or an iOS simulator or device — like Puppeteer drives a browser. Tap, type, swipe, screenshot, and above all inspect the UI hierarchy by semantic identifiers.

It is built to be invoked by AI agents, so its output and exit codes are a deliberate machine contract rather than only human ergonomics. It ships as a skill and a plugin rather than an MCP server — why.

Agent CLI

vk <command> — one-shot commands to read the screen as a semantic tree (or a screenshot) and act on it. Selector lookups auto-wait and scroll into view, so a flow needs far fewer explicit waits than you would expect.

Puppeteer for native mobile

A thin wrapper over the native Android and iOS automation runners, with zero runtime dependencies.

Natural-language tests

vk ai <file> runs plain-English tests: compiled once, then replayed model-free at roughly $0, calling a model only to self-heal a step that drifted.

CI-ready

vk suite runs a folder of tests as one gated pass/fail run. vk server exposes a real device over an authenticated tunnel, so a disposable CI runner with no phone attached can still drive it.

Where to go next

If you want to…	Read
Install it and drive a device in ten minutes	Your first test
Have an AI agent drive the device for you	Using it from an AI agent
Write a repeatable test	Writing test cases
Gate a pull request on a real device	Remote devices & CI
Decide whether CI should self-heal or fail	Self-healing in CI
Look up a command, flag or exit code	Reference
Understand why it is built this way	Internals
Work out what a failure means	Troubleshooting