> ## Documentation Index > Fetch the complete documentation index at: https://docs.noqa.ai/llms.txt > Use this file to discover all available pages before exploring further. # CLI for agents > Let a coding agent drive the noqa CLI — read the screen, debug on device, and author test cases. The noqa [CLI](/docs/cli) is plain commands in, JSON out — a natural tool for a **coding agent** like Claude Code, Cursor, or OpenAI's Codex. Instead of clicking through a dashboard, your coding agent can read the screen, drive the device, and author test cases as part of your normal loop: change code, ask it to test the change, get a pass/fail with screenshots. ## Install the CLI and skill Both live in the app's **Settings → Tools**: * **Install CLI** — links the `noqa` command into `~/.local/bin` and onto your `PATH`. That's the full command surface; every command and option is in the [CLI reference](/docs/cli). * **Install skill** — installs the `noqa-testing` skill for your coding agent, so it knows the commands and workflows without you spelling them out. ## What the CLI lets you do The command surface depends on the account. Two tiers, each adding to the last (all commands require being signed in): | | Free, signed in | Paid | | ------------------------------------------------------- | --------------- | ---- | | Inspect devices & the screen, drive actions | ✅ | ✅ | | Manage test cases, flows, tags, app context | ✅ | ✅ | | Run test cases with the noqa agent (`noqa runs create`) | — | ✅ | The last row is a real split: the device commands above are driven **directly** by your coding agent — it issues each `noqa screen` / `noqa action` itself. `noqa runs create` is different — it hands a saved case to the **noqa agent** (ours), which runs the whole thing on the device autonomously. ## Debug the app on a device You just built a feature and want your agent to check it on a real device — no test case, just an agent driving the app. Here the CLI is a connector: your coding agent issues commands and the noqa app runs them on the device. The agent drives it in an **inspect → act → verify** loop, never firing an action blind: 1. **Connect a device** — `noqa devices connect `. 2. **Get your app on the device** — make sure your build is installed and running. 3. **Loop, one step at a time:** * **Inspect** — `noqa screen` to read the current UI and confirm the target is there. * **Act** — one `noqa action …`, preferably targeting the element by plain-language description (`--description`) so noqa grounds it to the right spot; fall back to explicit relative coordinates (`--x/--y`, `0–1000`) only when grounding mislocates. * **Verify** — `noqa screen` again, or `noqa screenshot` for a visual check, to confirm the state changed as expected. Your coding agent runs this loop directly, deciding each action from what it just read. ### Reading the screen efficiently Because the agent inspects the screen on **every** step of that loop, how it reads the screen drives token cost. There are three ways, and they differ enormously — measured on the same screen (the Lingua Talks paywall): | Approach | Tokens | vs `noqa screen` | | -------------------------------------- | ------: | ---------------: | | `noqa screen` — cleaned element tree | \~800 | 1× | | Screenshot (vision) | \~1,500 | \~2× | | `noqa screen --full` — raw Appium tree | \~5,600 | \~7× | * **`noqa screen --full`** is the raw accessibility tree straight from Appium — every wrapper, container, and duplicated label. Complete, but noisy and heavy, and it balloons on complex screens. * **A screenshot** is cheap in tokens, but it's pixels only: the model has to infer where elements are and read small text visually, which hurts tap precision and misses anything off-screen. * **`noqa screen`** is our **cleaned element tree** — we strip the redundant nodes from the raw tree and keep the meaningful elements with their exact bounding boxes. Here that's **\~7× fewer tokens than the raw tree, and lighter than a screenshot** — while still giving the agent precise, structured positions to describe and act on. That's the tradeoff noqa optimizes: the most reliable signal (structure + exact positions) for the fewest tokens, so debugging stays fast and cheap. ## Automate the full QA cycle This is where the two agents work together. Your coding agent learns the app and builds the test cases, then hands them to the noqa agent to run on real devices — between them they stand up and maintain the whole QA ecosystem for your app. You describe what to cover; they do the rest. What that unlocks: * **Read your code.** The agent reads the relevant source — screens, navigation, business logic — to understand what a feature is meant to do before it touches the app. * **Explore your app.** The agent launches the app and walks through it on a device to learn how it works — screens, flows, and states — the way a new QA hire would. * **Remember your app.** What it learns — credentials, screen names, quirks, global rules — it keeps in the app's context, injected into every run. That knowledge compounds as more tests run, so the agent keeps getting better at your app. * **Write test cases.** It turns what it learned into saved test cases, pulling shared steps like login and onboarding into reusable flows so the suite doesn't repeat itself. * **Run full pre-release regression.** The noqa agent runs the cases against a fresh build and returns per-step pass/fail, checks, and screenshots — one case or the whole suite, on local devices or in the cloud, or in CI so every release passes the same checks. Because the agent validates each scenario on a real device before saving it (the [debug loop](#debug-the-app-on-a-device) above), the cases it writes are reliable from the start. Every command and option The mental model behind noqa