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
Inspect before use
Read the source instructions and check the requirements before you install this skill.
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 affectedRead the full source on GitHub (opens external page)