Write a good brief

Mo plans its own coverage, so the brief decides the boundary of the run. Include:

The target. For a web session, give the exact URL, with the path and query string of the area you want checked. A staging or preview URL is fine. For a mobile session, select the uploaded build in the composer and give no URL.
The scope. The flows or the area that count as in scope, and anything Mo must not touch.
The expected behavior. State the observable outcome that makes each flow pass. Include behavior that may look like a bug but is intended, such as an action hidden from an account without the required permission.
The accounts. Which account to sign in with, and which roles to use when the behavior depends on permissions.
The test data. Data Mo may create, data it must not modify, and any isolation rule such as one order per run.
The prohibited actions. Payments, deletions, outbound email, or anything else with a side effect you do not want.

The brief can come from a document instead of the composer box. Attach a file to the session and reference it, for example a CSV to upload or a release plan to test against. A connected MCP server can supply a document if it exposes a tool Mo can use to read it. Mo derives cases from the supplied context. See test from an existing spec or test plan.

An example brief

Shortened from a real release pass on a file storage and sharing product:

Target. https://app.staging.example.com, on an account with the new experience
enabled.

Product context. This release replaces the classic file browser with three new
surfaces: a home page of actionable cards, a persistent search-and-chat bar, and
an assistant that answers questions about the user's files. The classic jobs
must keep working: browse, upload, share with permission controls, preview and
comment, and search.

Accounts. Sign in as qa-owner@example.com. Use qa-member@example.com as the
share recipient on the same team, and check public share links while signed out.

Test data. The owner account already holds mixed files and folders, one shared
folder, one connected app, and one long document. Create files and folders
freely under /mo-runs, and modify nothing outside it.

Priorities. Upload, sharing, preview comments, search, the assistant, and the
new home page must work: a failure there blocks the release. Spend the most time
on the search-and-chat bar and the home page, because both are new.

Watch these. Renaming a folder failed in an earlier build, and the tooltip tour
collided with the search bar tooltip. Confirm both rather than assuming the
fixes hold.

Out of scope. Account management, offline mode, video editing, and PDF markup.
Note a serious problem if you meet one, but do not explore there.

Prohibited. No purchases, no deletes outside /mo-runs, and no outbound email to
a real address.

Two briefs that run well

Use either pattern to specify the target and scope. A P0 feature-area pass. One product area, its flows named, and a hard boundary on test data:

Target. https://staging.example.com

Scope. Order management: list, detail, refund, and export. Cover creating an
order, applying a refund, filtering by status, and refreshing after each change.

Sign-in. The staging QA account.

Test data. Create orders under the mo-runs customer only. Touch nothing shared
with other test accounts.

Out of bounds. Billing settings, user management, and admin surfaces.

A diff-window pass. This one needs workspace repositories selected, so the session can read the code itself. Give it a window instead of a feature list:

Target. https://staging.example.com

Scope. Commits merged to the default branch in the last 24 hours in the
checked-out repository. For each change, name the product flows it touches and
verify them on staging. Skip refactors, tests, and dependency bumps.

Sign-in. The staging QA account.

Test data. Do not modify shared workspace data.

The same pattern covers other windows: “commits since the last release tag”, “the diff for PR #412”, or “everything merged this week”.

Start with one area, read that report, then widen the scope. A narrow session lets you review coverage and access before adding more areas.

Run a session

Select the target, provide access, and follow the session.

Use cases

Releases, pull requests, mobile builds, previews, and local branches.

Get started

Essential guidelines

Set up Mo

Integrations

Working with Mo

Write a good brief

An example brief

Two briefs that run well

Next

Run a session

Use cases

​An example brief

​Two briefs that run well

​Next

Run a session

Use cases

An example brief

Two briefs that run well

Next