> 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/workflows.md).

# Run Ship Workflows

How to use Ship for application crawling, code analysis, pull-request impact, bug reproduction, regression creation, and AI-assisted engineering handoffs.

## Quick answer

Ship starts from a signal—an application crawl, code change, reported bug, or observed anomaly—and turns it into a bounded quality workflow. The durable output is not only a pass or fail. It is the source signal, execution scope, evidence, likely cause, regression coverage, and reviewer decision.

## Start with an application crawl

Use a crawl to establish an initial product map when a reachable test application is available.

1. Open **Autonomous SDLC → Crawl**.
2. Confirm the target environment and test identity.
3. Start a new crawl or review the onboarding crawl.
4. Watch the AQE Terminal for current activity.
5. Wait for a terminal result before evaluating coverage.
6. Review generated modules, journeys, requirements, and tests.
7. Strengthen assertions and add missing roles, states, and negative paths.

**Use case:** A team can establish a shared, reviewable starting point for a product whose coverage previously lived in manual knowledge or disconnected scripts.

## Analyze a repository

Code analysis gives Ship approved repository context for test generation and later change-impact analysis.

1. Authorize GitHub or GitLab with the narrowest suitable repository scope.
2. Confirm the repository, default branch, deployed application, and organization boundary.
3. Start code analysis and retain its analysis identity and status.
4. Compare discovered areas and flows with requirements and existing tests.
5. Add missing business context from tickets, designs, documentation, or recordings.
6. Review generated candidates before adding them to shared regression coverage.

Code analysis does not approve a pull request, merge code, or prove every behaviour in the application.

## Check a pull request against product behaviour

```mermaid
flowchart LR
    A[Pull request] --> B[Map files and affected flows]
    B --> C[Select relevant existing and candidate tests]
    C --> D[Run targeted regressions]
    D --> E[Preserve results, video, trace, and logs]
    E --> F{Evidence complete?}
    F -->|Yes| G[Reviewer records the decision]
    F -->|No| H[Run broader coverage or investigate]
```

Before relying on the result, verify the target deployment, environment, data revision, selected tests, and run outcome. A partial analysis, zero-test result, failed analysis, or missing execution evidence is not a passing release signal.

## Reproduce and investigate a reported bug

When a connected Jira, Linear, Slack, or service-desk report is eligible:

1. Preserve the original report, environment, timestamp, and reporter-observed outcome.
2. Identify missing prerequisites, data, identity, and stopping conditions.
3. Reproduce the behaviour in an approved environment.
4. Capture steps, screenshots or video, console and network evidence, and trace when available.
5. Distinguish product behaviour from test, data, environment, dependency, or access failures.
6. Present the likely root cause and suggested next action as a reviewable hypothesis.
7. Create a regression case when the defect is confirmed and rerun it after the fix.

## Use production signals safely

For eligible captured application activity, use the loop:

**Observe → identify an anomaly → reproduce in a controlled environment → review evidence → create a regression test → add it to the appropriate suite.**

Observed activity does not establish complete coverage across every user, role, browser, route, state, or business risk.

## Hand verified context to an AI coding agent

MCP lets an engineer ask Ship for focused quality context from an existing AI client. Keep the handoff small:

* Failed outcome and affected workflow
* Reproduction steps
* Relevant logs, trace, screenshots, or video reference
* Likely cause and its confidence or limitations
* Regression case and rerun status

Do not include secrets, unrelated source code, customer data, or unsupported conclusions in the prompt.

## Evidence checklist

* **Source:** change, defect report, session, requirement, crawl, or recording
* **Scope:** repository or application boundary, branch, environment, identity, and data revision
* **Analysis:** affected flows, selected tests, confidence, limitations, and fallback decision
* **Execution:** run identity, trigger, target, timestamps, status counts, and reruns
* **Investigation:** first meaningful failure, reproduction steps, logs, trace, screenshots, or video
* **Outcome:** confirmed defect, test or environment issue, suggested action, regression case, and verified rerun
* **Governance:** reviewer, approval, exception, release decision, and audit reference

For operating boundaries, see [Operate Ship safely](/ship/security-and-controls.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/workflows.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.