One prompt. One isolated QA setup.

Your coding agent already has the context

Traditional test-tool onboarding starts by taking you away from the work. You open another dashboard, create a hierarchy, copy credentials, configure a target, and translate product behavior into test syntax. The setup cost lands before the first useful result.

Agent-native onboarding starts where the product work already lives: inside the coding agent that understands the repository. One instruction gives that agent a clear outcome. QA.army supplies the public authentication and API contract; the coding agent handles the setup steps and asks only when essential information is missing.

This is not “put everything in a prompt.” Durable state still belongs in QA.army. The prompt initiates a governed workflow that creates ordinary product objects with normal authorization, idempotency, and audit boundaries.

How the one-prompt QA setup works

1. The agent discovers the protocol. It reads QA.army’s public authentication instructions and OpenAPI contract instead of guessing endpoints or permissions.
2. You approve one claim link. The agent opens a short-lived registration link. You sign in and return the one-time code shown on the claim page. Reusable credentials never belong in the prompt.
3. QA.army resolves the authorized scope. The setup creates or reuses the correct Workspace and Project for the application URL. Workspace membership remains the authority.
4. One critical journey becomes a saved Test. The agent describes the most important user flow in plain language. QA.army validates and saves an ordered Web Test rather than leaving the plan inside chat history.
5. An explicit Run returns a truthful result. The agent starts one Run, waits for PASSED, FAILED, ERROR, or CANCELLED, and returns the Project dashboard URL.

Idempotency matters here. Repeating the same setup should reuse the intended Workspace, Project, and generated Test instead of filling the account with duplicates. A new Run is created only for a new explicit execution request.

What “isolated Workspace” means

A QA.army Workspace is the tenant, authorization, collaboration, and billing boundary. It is not a folder label and it is not an agent session. Every Project, Test, Run, result, and evidence read is checked against that boundary.

The coding agent does not choose an arbitrary Workspace identifier and hope the API accepts it. QA.army derives scope from server-owned records and verifies the authenticated principal’s membership. A Project belongs to one Workspace; a Test belongs to that Project; a Run belongs to that Test.

The claim URL and one-time code are temporary ceremony, not product credentials to paste into Test text. The agent stores reusable identity material in the operating system’s credential store and keeps its short-lived access token in memory. Passwords, API keys, session tokens, and one-time codes stay out of prompts, saved Tests, evidence, and logs.

What one prompt sets up

The useful output is not an “agent configured” message. It is a working, inspectable QA setup:

• an authorized Workspace, created or reused through the normal product boundary;
• a Web Project connected to the application URL;
• one durable, plain-language Test for a critical user journey;
• one explicit Run with a deterministic terminal status; and
• a Project dashboard URL so the team can review and continue the work.

A saved Test and a Run remain separate. Generating a Test does not silently spend a Run or touch the target. Execution begins only through the Run operation. That distinction keeps authoring safe, repeatable, and visible.

A result must say what happened

PASSED means every required expectation held with the required evidence. FAILED means the product violated an expectation. ERROR means QA.army could not determine a trustworthy product result. Infrastructure uncertainty must never be dressed up as a product failure—or a pass.

What is available now?

QA.army’s agent identity flow, public Product API, production CLI, saved Web-Test authoring, and direct Web Run path are available now. The complete clean-environment journey—paste the exact setup instruction into a fresh coding agent and repeat it idempotently—is in final production verification.

That status is deliberate. A public prompt should be the last step, not the first claim. We are verifying the same path customers will use: one claim link, one one-time code, no dashboard setup, no copied reusable credential, one saved Test, one explicit Run, and a working dashboard link.