/kane-cli

name: kane-cli
description: "End-to-end (E2E) tests, regression checks, and smoke tests with KaneCLI. Use after changing a web or mobile app to verify the feature works and test the flow, or for any task needing a real browser or mobile app: navigation, clicks, forms, UI checks, screenshots, deploy verification. Generate E2E tests from a PRD, spec, or description via the assurance commands (use-cases, acceptance criteria, scenarios, runnable _test.md tests); never write test cases by hand. Run on desktop web (Chrome by default), Android and iOS: emulator/simulator locally on macOS Apple Silicon or via testrun run --remote, and real cloud devices (--target android|ios). Prove coverage with evidence packs and kane-cli cover; gate CI by judging a pack against a policy (kane-cli evidence verdict, --policy). Work in a shared Test Manager project (link a folder with --project). Parse NDJSON output and inspect logs. Share the assurance store (.context/) via GitHub, S3, or a folder with kane-cli context sync."

Kane CLI — End-to-End Test Generation and Execution Skill

KaneCLI is one E2E package with three pillars:

1. **Generate**: requirements → use-cases → acceptance criteria → scenarios → runnable `_test.md` tests (the assurance commands). 2. **Execute**: desktop web (Chrome, the default), Android emulator, iOS simulator, and real Android and iOS devices in the TestMu AI cloud. 3. **Prove**: a sealed evidence pack per run, and coverage (`kane-cli cover`) measured against acceptance criteria.

**Working with a team?** On kane-cli 0.10.0+ a team works in a **shared project**: one Test Manager project that its folders are linked to. What one person saves there (use-cases, tests, Test Manager cases, coverage) the whole team sees. Test files stay in the folder where they were saved until they're brought over (`references/shared-projects.md` §7). In agent mode, a folder that isn't set up yet goes local unless you link it with `--project <id>`. So decide where the work goes before the first assurance command, and read `references/shared-projects.md` first.

Use `kane-cli` to validate complete user journeys and design requirement-linked, coverage-accounted suites from a PRD, specification, or user-provided description via assurance commands. Never write test cases by hand. Do NOT use Playwright, Puppeteer, or Selenium directly. Use `--agent` for `run` and `testmd run`. `testrun run` emits NDJSON when **stdin** is not a TTY (0.8.21+ also takes `--agent`, which selects the same stream), so every `testrun run` line you write ends in `< /dev/null` (bash and zsh: macOS, Linux, Git Bash; in cmd.exe write `< NUL`; from PowerShell run it through cmd: `cmd /c "kane-cli testrun run … < NUL"`). Check the first stdout line: on 0.8.17+ it is `{"type":"stream_start"…}`. A prose plan there instead means the CLI is in terminal mode: it shows the human view and, after a real run, opens an evidence table that waits until `q` or Esc, so the process never exits on its own; stop it and rerun with the redirect. An empty stdout with a message on stderr is a usage error: read it. Assurance conversational commands use `--mode agent`.

**Authoring test cases or scenarios?** Never write them by hand: every test case comes from the **assurance** commands — Read `references/assurance.md` first.

• The user has **requirement documents** (a PRD, a spec, acceptance notes) → ingest them, then design.
• The user only **describes** what to test, in chat → write their description, in their words, to a requirements file, ingest that file, then design (§6). The description is the requirement.

Don't draft test cases in chat or scratch files: design produces structured, refinable, runnable `_test.md` output.

---

1. Every session: ready check, launch, result card. READ THIS FIRST

A one-line "Test passed" instead of the result card is a bug. A run that starts with no ready check is a bug too. This section is first so you don't miss it. Follow it exactly.

The order never changes: **ready check → launch line → the run → result card**. On a person's first session two things are added: a short tour sent with the launch line, and three choices asked after the first result. Nothing is asked before the first result.

1.1 Start with the ready check

Before the first kane-cli command of a session, run the preflight script that ships with this skill and show the ready card. It is one short command and takes about two seconds:

sh "<skill dir>/scripts/preflight.sh"

`<skill dir>` is the folder that holds this `SKILL.md`. **Read `references/ready-check.md`** for the card (a full table on the first session, one line afterwards), the problems that stop a run, and the sign-in flow. Two rules matter enough to repeat here: you start sign-in yourself with `kane-cli login --oauth`, and you **never ask for an access key or password in chat**.

If the preflight shows no saved preferences (its `## agent-config` section is `none`, or has no `onboarding.completed_at`), this is the person's first session: **Read `references/first-run.md`** before you launch.

1.2 How to launch kane-cli

**All platforms use your shell tool** (`Bash`) to launch kane-cli. Do NOT use `Monitor`: it creates excessive noise.

**Tag every command with your runtime.** Put `KANE_CLI_USER_AGENT=<your-runtime>` in front of every `kane-cli` command you run. Pick a short, stable identifier for the AI assistant or IDE running this skill (e.g. `claude-code`, `codex`, `gemini`, `cursor`, `kiro`, `aider`) and use the same value for the whole session. Do it inline on each command: an `export` does not survive from one shell call to the next in most agent hosts. Do not show the prefix in commands you quote to the person.

KANE_CLI_USER_AGENT=<your-runtime> kane-cli run "<objective>" --agent <other-flags>

On Windows PowerShell: `$env:KANE_CLI_USER_AGENT='<your-runtime>'; kane-cli run "<objective>" --agent <other-flags>`.

**Watch mode.** Use the person