CLI for agents

The noqa 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.
• 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): 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 <device-id>.
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):

• 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 above), the cases it writes are reliable from the start.