Every recipe below is the same primitive: a target plus a brief, and a session
that plans the cases, works them in parallel, and reports only the bugs it
reproduced. What changes is where the brief comes from and which settings the
run needs. The brief fields are in write a good brief; the commands
are in use the Mo CLI.
Bug bash a P0 feature area
Point a session at one product area and let the explore agents take it apart.
This is the pass to run before a release or a migration: Mo covers the area the
way a QA team would, except every case runs in its own hosted browser at once.
-
Pick one feature area and keep the brief narrow. Name the flows inside it,
the account to use, and the areas to leave alone:
-
Start the session:
mo start prints the session JSON. Save sessionId for later commands, and
open webUrl to watch.
-
Read the bugs as they land with
mo status <session-id> --full, or export
everything with mo report <session-id> once the session goes idle.
A pass at this shape produced reproduced bugs like a fresh row that disappeared
from a duplicated view after refresh, an edited item that never persisted after
reload, and a staging link that routed to a production login. Each entry arrives
with reproduction steps and a recording, so a fix starts from evidence instead
of a Slack message.
--granularity high (the default) suits a P0 area: explore agents exercise
every independently operable control and name whatever they could not finish.
Drop to low for a fast smoke pass over the same scope.
Regression the last 24 hours of diffs
Select the repositories on the Mo workspace page once. After that, every
session starts from a fresh snapshot of them at
/home/user/workspace/repos/<repo-id> with read-only Git credentials. The
session agent can read the code, run git log over the last day, and aim the
explore agents at the flows those commits touched.
-
Connect GitHub in Settings > Integrations, then pick the repositories on
Mo > Workspace.
-
Give the brief a diff window instead of a feature list:
-
Start the session the same way:
Only the default branch is refreshed when the session starts. To diff a release
branch or a feature branch, say so in the brief; Mo fetches it inside the
sandbox before it reads the log.
A daily diff pass is what a
schedule is for: one cron
expression, one prompt, and the report is waiting in the morning. On a real
product this shape surfaced a crash dialog on Tab inside a new meeting template,
a consent checkbox that would not toggle, a model selector that crashed the
routines view, and a dialog that deleted the title of the page behind it. None
of those needed a test written first.
Run Mo on a pull request
With the Momentic GitHub App installed, Mo takes the change itself as the scope:
it scopes the session to the pull request, posts the result as a comment, and
reports a status check you can require before a merge. A comment on the pull
request also starts a scoped run. See
use GitHub context.
Keep a scheduled diff pass for the wider coverage a PR run does not attempt: the
PR run answers “did this change break the flow it touched”, and the scheduled
pass answers “did anything else move”.
Fix what it found, then recheck
mo report is built for the coding-agent loop: it exports the report as files
your agent reads, so the fix and the recheck happen in one session of work.
-
Export once the session is idle:
The directory holds
report.json (a manifest into bugs.json,
testCases.json, verdicts.json, and triage.json) plus one recording per
bug. Hand mo-report to Claude Code, Codex, Devin, or Cursor.
-
The agent reads each bug’s expected and actual behavior and its reproduction
steps, fixes the defect in your checkout, and reruns the original
reproduction locally.
-
Recheck through the same session.
mo send interrupts the active turn, so
wait until Mo is idle, then name the bug and ask for the recheck:
Compare the new verdicts.json against the baseline. Call a fix verified
only when the original reproduction passes fresh, not when the code looks
right.
The mo-qa skill encodes this whole loop, including
the baseline export and the wait-for-idle rule. /mo-qa fix the bugs Mo found
is the supported way to run it.
Test from an existing spec or test plan
Upload the document to the session, then point Mo at the sandbox path it prints.
A local path means nothing inside the sandbox, so the upload is the handoff:
Mo derives the cases from the document. A Confluence page works the same way
once Atlassian is connected in Settings > Integrations: give the page URL or
ID in the brief and Mo reads it as the source.
Test a preview deployment
Connect Vercel in Settings > Integrations, keep deployment protection on,
and give the preview URL in the brief:
Mo detects the hosting platform and the protection type from its own traffic and
applies the connected bypass. A preview run leaves production alone, which makes
it the right target while a change is still moving. See
test a protected target for the
supported platforms and the limits.
Test a local branch
Start a tunnel for every address the flow needs, then start the session with the
tunnel ID:
Keep the exact local URL in the brief: Mo resolves it through the tunnel, not
through the public internet. One tunnel holds every address it was started with,
and mo tunnel stop <tunnel-id> revokes Mo’s access when the pass ends. See
test a local build through a tunnel.
Test a mobile app
Upload the build to a channel and a tag the same way a Momentic mobile test uses
it, then select it in the composer. Give no URL: the brief describes the flows
and the accounts instead. Mo installs the build on a remote simulator or
emulator and runs the same agent structure as a web pass. See
iOS app setup and
Android emulators.
Repeat a pass on a schedule
Open Schedules in the Mo section of the app. A schedule holds a name, the
prompt, a cron expression, and a time zone. Each occurrence starts a new
session, and the schedule page lists the past runs and their reports. The
nightly diff regression above and a weekly full-area pass are the two schedules
most teams run.
Some ways of running Mo are not available yet. See
not available yet. 
