> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/ship/getting-started.md).

# Set up a Ship Workspace

A step-by-step guide to starting a Ship trial, connecting a safe application, choosing quality priorities, and reaching the autonomous quality dashboard.

## Quick answer

Ship onboarding has seven guided steps: describe the product and connect a reachable environment, choose quality priorities, optionally authorize a code provider, optionally connect issue and collaboration tools, connect an AI agent through MCP, invite teammates, and review the trial before opening the dashboard.

For a first evaluation, use a non-production environment with disposable test data. Do not point the crawler at production merely because the URL is publicly reachable.

## Before you begin

Prepare:

* A work email and a unique organization name
* A staging, QA, or intentionally public test application that Ship can reach
* A test identity if the application requires login
* The approved repository list if you plan to connect GitHub or GitLab
* An issue tracker or Slack workspace only if those integrations are in evaluation scope
* An owner who will review generated coverage and evidence

{% hint style="warning" %}
The crawler can perform actions it discovers, including creating, updating, or deleting test records and triggering connected workflows. Use a controlled environment, disposable data, and a least-privilege test identity. Disable CAPTCHA and two-factor authentication only for that isolated test identity when your security policy allows it.
{% endhint %}

## 1. Create the organization

1. Open the [Ship trial signup](https://accounts.contextqa.com/onboard?mode=signup).
2. Create or sign in to your ContextQA account.
3. Enter your name, a unique organization name, and an optional company website.
4. Decide whether the company website should be added to the Knowledge Base.
5. Create the organization.

If the work-email domain matches an existing organization, Ship may offer to request access. Choose the existing organization only when its administrator expects the request; otherwise use a clearly named evaluation organization.

### Emails to expect

Ship sends two transactional messages during successful signup:

1. **Email verification** — contains a short-lived, one-time code used only on the signup tab.
2. **Workspace ready** — confirms that the account is active and provides the workspace and MCP destinations.

Treat the verification code, work email, tenant URL, and MCP destination as private account information. Do not paste them into tickets, public documentation, screenshots, or chat channels.

## 2. Describe the product and connect the application

Write three or four plain-language sentences that explain:

* What the application does
* Who uses it
* Which workflows matter most
* What failures would be costly or confusing

Then enter the staging or QA endpoint. Turn on **Login required to use the app** only when the test environment requires credentials, and use a dedicated test account.

Select **Check connection**. Continue only after Ship reports that the connection succeeded.

**Business outcome:** Ship receives the minimum product and environment context needed to start mapping behaviour instead of waiting for a manually authored test plan.

## 3. Choose the initial quality priorities

Select the current problems that should shape the first dashboard experience:

* Escaped bugs
* Behaviour drift
* Slow code reviews
* Flaky tests
* Pull-request checks

Also select the evaluator's role and the team's current testing maturity. These answers personalize the starting experience; they do not replace documented acceptance criteria.

## 4. Connect code only when it is in scope

Ship supports GitHub and GitLab during onboarding. Provider authorization is separate from signing in to ContextQA.

1. Select the code provider.
2. Review the requested permissions and organization boundary.
3. Prefer selected-repository access over broad account access when the provider offers it.
4. Authorize only the evaluation repositories.
5. Return to Ship and verify the selected repository and default branch.

You can select **Skip for now** and connect code later. Application crawling can begin without granting repository access.

## 5. Connect bug and collaboration context

Optionally connect:

* **Jira** for projects, issue types, and transitions
* **Linear** for teams, issues, and labels
* **Slack** for reproduced findings

Start with one bounded project or team. Verify what Ship may read and where it may write before enabling automatic reproduction or notifications.

## 6. Bring Ship into an AI agent

The MCP onboarding step provides client-specific instructions for ChatGPT, Claude, Codex, Claude Code, and Cursor. One MCP connection can support three common jobs:

1. Explain why a test failed.
2. Show what a pull request puts at risk.
3. Pull a reproduced bug, its evidence, and its likely cause into an engineering workflow.

The downloadable agent skill contains operating guidance and should not contain ContextQA credentials. Complete OAuth in the selected MCP client and verify the connection from the MCP page.

## 7. Invite teammates and open the dashboard

Invitations are optional during onboarding. Skip this step when you are still validating scope; teammates can be added later from **Team & access**.

The final trial screen summarizes the trial duration, included credits, and what remains accessible after the trial. Choose **Go to dashboard** to watch onboarding work continue in the AQE Terminal.

## Verify the onboarding result

You are ready to evaluate Ship when:

* The application endpoint shows a successful connection
* A crawl appears under **Autonomous SDLC → Crawl**
* AQE Terminal shows current activity
* The dashboard identifies the trial period and remaining time
* The organization has no unnecessary repository or integration permissions
* A named reviewer owns generated tests and release decisions

## What happens next?

The onboarding crawl runs in the background. Modules, tests, and provisional coverage appear as Ship learns the application. A crawl that is still processing is not evidence of completed coverage; wait for a terminal status and review generated artifacts before using them in a release decision.

### Example onboarding result

In a verified evaluation against the intentionally public [The Internet](https://the-internet.herokuapp.com/) test application, the onboarding crawl completed and produced 29 accepted test candidates:

| Category         | Candidates |
| ---------------- | ---------: |
| Positive         |          4 |
| Negative         |          5 |
| Edge             |          3 |
| Field validation |          3 |
| End to end       |          3 |
| Functional       |          8 |
| Boundary value   |          3 |

The candidates included authentication and dynamic-control journeys, element creation and removal, checkbox state management, dropdown selection, numeric input, and JavaScript alert handling. This is an example outcome, not a guaranteed count for another application. Review prerequisites, variables, assertions, and business priority before promoting generated candidates into a regression suite.

Next, see [Run Ship workflows](/ship/workflows.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://learning.contextqa.com/ship/getting-started.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.