Skill detail

mo-qa

Use Momentic's `mo` CLI to run and control Mo, Momentic's cloud autonomous QA agent. Use when starting or continuing Mo sessions, reading their output or status, stopping active work, answering Mo, transferring files, exporting reports, or finding and fixing bugs in a local codebase with Mo.

Why we recommend it: Runs and controls Momentic's cloud autonomous QA agent for testing web applications and finding bugs.

Needs (stated): Credentials

MatchDirectRecommended for Testing
Sourcemomentic-ai/​skillsExternal source
Reported installs13,849Popularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: mo-qa
description: Use Momentic's `mo` CLI to run and control Mo, Momentic's cloud autonomous QA agent. Use when starting or continuing Mo sessions, reading their output or status, stopping active work, answering Mo, transferring files, exporting reports, or finding and fixing bugs in a local codebase with Mo.
---

# Run QA with Mo

Mo is Momentic's autonomous QA engineer. It runs in a hosted sandbox, where it
can test web applications with a browser, inspect network traffic, run code and
shell commands, delegate exploration, and report test cases and product bugs.
Treat its filesystem and environment as remote, not as the user's machine.

When the user asks to fix bugs found by QA, also read
[Repair loop](references/remediation-loop.md) and continue through diagnosis,
repair, and verification. Otherwise, run QA without changing application code.

## Setup

Run `mo version`. If it fails or recommends an update, read
[Installation](references/installation.md).

Assume authentication is already configured. If an operational command reports
an authentication error, read [Authentication](references/authentication.md).

Use the target implied by the conversation. If it is unclear, ask the user what
to test. For a local or private target, read
[Tunneling](references/tunneling.md) and retain its `tunnel_id`. For a public
target, use its exact URL.

## Write the QA brief

Treat the brief as the whole input. State:

1. **Target URL:** Include the exact path and query the change affects.
2. **Expected behavior:** Explain what changed and what it should now do in
   product terms.
3. **Sign-in instructions:** Name the login method and test account to use.
4. **Test data rules:** State what Mo may create and what it must not touch.
5. **Out-of-bounds actions:** Call out deletions, payments, emails, production
   data, bulk operations, and any other destructive action. Mo may take
   destructive actions if the brief invites them.
6. **Acceptance criteria:** List the checks that decide pass or fail.

Use the user request, task specification, and repository context to fill in the
brief. State reasonable assumptions; ask when missing information materially
changes the scope or requires credentials or permissions you don't have.

## Run a session

Write the brief before invoking the CLI, then pass it as one quoted argument:

```bash
brief=$(cat <<'EOF'
Target URL: https://preview.example.com/checkout?variant=express
Expected behavior: Express checkout now keeps the selected shipping method when the customer returns from payment.
Sign-in: Use the staging QA buyer account already provisioned for Mo.
Test data: Create test carts and orders only. Do not modify shared catalog data.
Out of bounds: Do not submit payment, send emails, delete data, or run bulk operations.
Acceptance criteria:
- The selected shipping method remains selected after returning from payment.
- The order total does not change.
- Standard checkout still works.
EOF
)
session_json=$(mo start "$brief")
session_id=$(jq -r .sessionId <<<"$session_json")
web_url=$(jq -r .webUrl <<<"$session_json")
```

Starting returns before Mo finishes. Preserve both values: every later command
needs `session_id`, and the user can watch or join through `web_url`.

Use start settings only when needed:

- `--tunnel "$tunnel_id"` connects the session to a configured tunnel.
- `--momentic-mode` uses smarter Momentic browser tools; omit it for faster
  Playwright MCP.
- `--max-concurrency <count>` caps concurrent sub-agents. Omit it by default;
  pass it only when the user specifies a limit before the session starts.

These settings are chosen when the session starts.

Concurrency cannot be changed on an existing session. A lower value reduces
parallel model and browser load, which can help when Mo hits provider rate
limits or overwhelms a local target server. If either happens, stop the current
session and start a fresh one with a lower `--max-concurrency`; do not try to
repair the affected 
Read the full source on GitHub (opens external page)
Context

Related work