Install and set up
setup prompts for your API key (mint one in the Portal, in the workspace you want to test in), verifies it, stores it in ~/.testsprite/credentials, and installs the TestSprite agent skills into the project. Replace AGENT with claude, codex, cursor, cline, windsurf, antigravity, kiro or copilot; it takes a single target. Without --agent, setup installs for every agent it detects in the project, or claude if none. Run it once per project, and confirm what landed with testsprite agent status.
For CI or other non-interactive environments:
- With a coding agent
- From the terminal
The two installed skills mean you describe behavior and ask for a verdict; the agent runs the CLI.Asking for a verdict (“run it to a verdict”) tells the agent a plan that was never run does not count. The agent shows you the drafted plan before creating it, ends every change with a verdict line (
Prompts to start with:
passed, failed, blocked or inconclusive) and a dashboard link, and says so explicitly when it could not run a test.To keep the agent on track:- Pin the project. The verify skill (not the CLI) resolves the project from
TESTSPRITE_PROJECT_ID, thenprojectIdin.testsprite/config.json, then a name match intestsprite project list, then asks you. Commit the pin to remove ambiguity:{ "projectId": "proj_8f0f6" }. - Keep credentials in place. The skills check
testsprite auth statusand stop if the CLI is missing or unauthenticated; they never install software or set keys. Re-run setup if they report it. - Know the cost. Reruns of unchanged tests are billed like a fresh run; see Rerun & Auto-Heal.
- Check skill health. After upgrading the CLI,
testsprite agent statusflagsstaleor hand-modifiedskill files and exits1when any need attention. See Coding Agent Integration. - Silence the nudge. Set
TESTSPRITE_NO_SKILL_WARNING=1if you drive the CLI by hand in a repo without the skill.
Find or create a project
--local 3000 instead of --url (shorthand for --url http://localhost:3000). If your account is not yet on the V3 platform, the CLI refuses it with exit 7 and reason local-origin-requires-v3; use --url with a public URL, or create the project in the Portal. Runs against a local address open a tunnel automatically; see Environments.
To test another deployment, add a named environment and select it with --env <name>; omit --env for the Default.
Create and run a test
Write a plan file (JSON withprojectId, type, name and a planSteps[] array) describing the behavior to verify. --run --wait triggers a real cloud run in a real browser and blocks until the verdict:
0 means passed; 1 means failed or blocked (see Exit codes). The --output json shape is a stable contract; when projectId and testId are known it includes a dashboardUrl for human review. See Output & Scripting.
When it fails, get the bundle
snapshotId.
test failure get always returns the latest failure. To pin a specific run, use testsprite test artifact get <run-id>. The bundle needs saved test code, so a test that has never passed, or has only run through a tunnel, returns exit 4 with reason no_code; read testsprite test steps <test-id> and the summary instead.
Fix and rerun
--no-auto-heal to replay the saved script exactly. See Rerun & Auto-Heal.
Where to go next
Coding Agent Integration
Agent targets, install flags and skill health
The Agent Loop
Why create, run, read, fix, rerun compounds coverage
Creating Tests
Plan files, code files and batch create
Command Reference
Every command, flag and exit code