kane-cli

Kane CLI - TestMu AI (Formerly LambdaTest)

From requirements to verified results. KaneCLI generates your end-to-end tests (use-cases, acceptance criteria, scenarios, tests), executes them on desktop web, Android and iOS (emulators, simulators and real devices), and proves what they cover. Use it from your terminal, your CI, or your AI coding agent.

---

One E2E package: generate, execute, prove

  1. GENERATE                       2. EXECUTE                          3. PROVE
  ───────────                       ──────────                          ────────
  requirements                      Desktop web   Chrome                evidence   a sealed pack per run
  (PRD, spec, or a description)     Android       emulator              coverage   proven vs owed, per
        ▼                                         real device                      acceptance criterion
  use-cases (every claim cited)     iOS           simulator             maintain   reconcile the suite when
        ▼                                         real device                      requirements change
  acceptance criteria
        ▼
  scenarios
        ▼
  tests (_test.md) ───────────────► run · testmd · testrun ───────────►

1. Generate

Give kane-cli a requirements document, or describe the feature, and it designs the suite: use-cases, then acceptance criteria, then scenarios, then one runnable test per scenario. Every test stays linked to the acceptance criteria it verifies. These are the assurance commands.

kane-cli context ingest ./prd.md               # snapshot the requirements into a local store
kane-cli context extract                       # AI proposes use-cases; every claim cites the source
kane-cli context review                        # you decide what's trusted
kane-cli design tests --use-case uc-checkout   # acceptance criteria → scenarios → one _test.md per scenario

Each design decision can be replayed later with kane-cli design explain. (Generating tests →)

2. Execute

The same plain-English tests run on every target:

Target	Flag	Runs from
Desktop web (Chrome)	default	macOS, Linux, Windows
Android emulator	--target emulator	macOS Apple Silicon, or any machine with testrun run --remote
iOS simulator	--target simulator	macOS Apple Silicon, or any machine with testrun run --remote
Android real device	--target android	Any machine, on TestMu AI cloud devices (plan required)
iOS real device	--target ios	Any machine, on TestMu AI cloud devices (plan required)

kane-cli run "Go to https://example.com and assert the title contains 'Example'" --agent    # desktop web
kane-cli run "Sign in and open the account tab" --target android --app ./app-release.apk   # real Android device
kane-cli testmd run tests/checkout_test.md --agent                                         # a saved test, replayed from cache
kane-cli testrun run --tags smoke --parallel 4 < /dev/null                                 # a whole suite

(Running tests → · Mobile testing →)

3. Prove

Every run seals an evidence pack: steps, screenshots, logs and failures in one file. kane-cli cover then reports what execution proved against each acceptance criterion, and what the design still owes. Coverage is measured against requirements, not test counts. When the requirements change, kane-cli maintain reconcile walks you through what the change means for the suite.

kane-cli cover                 # proven vs owed, per acceptance criterion
kane-cli maintain reconcile    # update the suite after a requirement changes

(Evidence → · Coverage →)

---

Contents

• What you type. What you get back.
• Where it fits
• Install
• First run (under 60 seconds)
• Commit tests as Markdown (testmd)
• Every run produces evidence
• Commands
• Troubleshooting
• Updating
• Documentation, support, contributing

---

What you type. What you get back.

You give kane-cli a plain-English objective. It launches a real Chrome browser (or a mobile device, with --target), drives it to completion, and returns structured results.

$ kane-cli run "Go to https://news.ycombinator.com and store the title of the top story as 'top_story'" --agent

{"step":1,"status":"passed","remark":"Opened news.ycombinator.com"}
{"step":2,"status":"passed","remark":"Identified the top story by position"}
{"step":3,"status":"passed","remark":"Stored the title as 'top_story'"}
{"type":"run_end","status":"passed","duration":7.4,"final_state":{"top_story":"Show HN: A new SQLite extension for…"},"summary":"Captured the top Hacker News title.","test_url":"https://test-manager.lambdatest.com/…"}

Exit code 0. The browser opened, the task ran, the value was extracted, the run was uploaded to the dashboard. That's the loop.

Where it fits

In your terminal and CI. Generate a suite from your requirements, commit the tests as Markdown, and run them locally, in CI, on a schedule, or on the cloud grid. Structured NDJSON output pipes into anything.

As the validation layer for AI coding agents. Cursor, Claude Code, GitHub Copilot, Codex, Gemini, and Antigravity all need a way to check that the code they just wrote works, in a real browser or a real app. Install the kane-cli skill once; the agent generates and runs tests to check its own work before committing. (Skill setup →)

---

Install

npm (recommended, requires Node 18+)

npm install -g @testmuai/kane-cli

Homebrew (macOS / Linux, no Node required)

brew install LambdaTest/kane/kane-cli

Shell script

curl -fsSL https://raw.githubusercontent.com/LambdaTest/kane-cli/main/install.sh | sh

Pin a version: append -s -- --version 0.2.6.

Chrome (required)

kane-cli launches your locally installed Google Chrome (stable channel) via the DevTools Protocol. Chrome must be present at one of the standard system paths (/Applications/Google Chrome.app/... on macOS, /usr/bin/google-chrome on Linux, C:\Program Files\Google\Chrome\Application\chrome.exe on Windows).

• Homebrew auto-installs Chrome via the google-chrome cask — nothing to do.
• npm install -g / npx: install Chrome separately if not already present. On first kane-cli run, kane-cli verifies Chrome is reachable and produces a clean per-platform error with install instructions if not — re-run after installing Chrome.
• Non-standard Chrome location — point kane-cli at the binary with KANE_CLI_CHROME_PATH=/path/to/chrome.
• Skip the runtime check (CI / air-gapped) — set KANE_CLI_SKIP_BROWSER_DOWNLOAD to any truthy value (1 / true / yes). kane-cli will fall back to whatever chrome resolves on PATH.
• Slow / cold CI runners — if Chrome is slow to come up, raise the per-attempt CDP readiness timeout with KANE_CLI_CDP_TIMEOUT_MS (default 30000) and/or the launch-retry count with KANE_CLI_CDP_RETRIES (default 2; 0 = single attempt).

Full install reference (platforms, updates, uninstall): docs/user-guide/installation.md. Chrome environment variables: docs/user-guide/configuration.md.

Mobile (local on macOS Apple Silicon, or on the cloud grid from any machine)

kane-cli can also run native app tests on real Android and iOS devices, or on an iOS Simulator or Android Emulator. It is off by default, so your web runs are unaffected.

• Locally — macOS Apple Silicon (arm64) only. Install the platform tooling you already use: Xcode (for iOS), or Android Studio with one arm64-v8a AVD (for Android); sign in and install kane-cli's managed test tooling: kane-cli login && kane-cli doctor --target simulator --install; then kane-cli run "<objective>" --target simulator --app ./MyApp.zip.
• On a real device — from any machine, with no mobile tooling: kane-cli run "<objective>" --target android --app ./app.apk (or --target ios --app ./MyApp.ipa) runs on a real device in the TestMu AI cloud. Needs KaneAI Max (one real device) or KaneAI credits + Real Device Plus Automation Cloud — see Real devices.
• On the cloud grid — from Linux, Windows, or any Mac, with no mobile tooling: kane-cli testrun run --match '^tests/app/' --remote --device-name "Pixel 7" --os-version 14 runs a saved mobile suite on a HyperExecute emulator or simulator (needs a LambdaTest plan with HyperExecute macOS runners and kane-cli plugin install remote-execution).

Full setup and prerequisites: Mobile testing · Remote runs on the cloud grid.

First run (under 60 seconds)

# 1. Authenticate (interactive in a terminal; flag-based in CI)
kane-cli login

# 2. Run an objective
kane-cli run "Go to https://example.com and assert the page title contains 'Example'"

# 3. Inspect the result
echo $?    # → 0 if passed, 1 if failed

For automation use (recommended whenever you want to parse output), add --agent:

kane-cli run "<objective>" --agent

--agent switches stdout to NDJSON (one JSON event per line). UI rendering goes to stderr and stays out of your way.

Running kane-cli --tui opens an interactive TUI for authoring and exploring objectives. See docs/user-guide/getting-started.md and docs/user-guide/running-tests.md for the full TUI walk-through and slash commands.

---

Commit tests as Markdown (testmd)

kane-cli run is one-shot. For tests you want to keep — login flows, smoke tests, regression suites — write a _test.md file and commit it to your repo. Each step is a plain-English objective; on the first run the agent works it out and saves a recording, and every run after that replays from cache in seconds with no LLM cost.

---
mode: testing
---

# Amazon search

## Open Amazon
Open https://www.amazon.com.

## Search for headphones
Type "wireless headphones" into the search box and submit.
Verify at least one product result is visible.

kane-cli testmd run amazon_test.md

What you get:

• Replayable — passed steps reload from cache on the next run; only edited steps re-author.
• Composable — @import ./helpers/login.md lets many tests share a login (or any other) flow. Edit one helper, every test that uses it picks up the change.
• Reviewable — every run writes a human-readable Result.md next to the test. Commit output-<name>/ alongside the test so teammates and CI replay the exact same recordings.
• Recordable from a live session — kane-cli run "<objective>" --name my-flow writes .testmuai/tests/my-flow_test.md on exit, ready to move into your repo.