Integrations

Connect QualityMax to the tools where your team already plans, writes, and reviews code. Start with MCP for coding agents, then bring the generated tests and execution evidence into your normal repository and CI workflow.

Smithery

QualityMax MCP on Smithery is the fastest managed connection path. Add the server and complete its OAuth flow:

npx -y smithery mcp add qualitymax/qualitymax-mcp

List the available tools before invoking one:

npx -y smithery tool list qualitymax/qualitymax-mcp

Keep credentials in the OAuth flow and your client’s secure storage. Begin with read-only discovery, review tool inputs before state-changing actions, and use a dedicated test target.

Direct MCP clients

QualityMax also connects directly to Claude Code, Codex, Antigravity, and OpenCode. Follow the coding agent MCP quickstart for client-specific configuration, a bounded first crawl, test generation, execution, and evidence review.

What to connect next

• Repository: keep generated Playwright, pytest, Jest, Go, Rust, or k6 tests alongside the code they verify so changes remain reviewable.
• CI/CD: run approved tests in your existing pipeline and preserve traces, screenshots, videos, and logs as evidence.
• QualityMax web app: use the web app quickstart when you prefer to create the project and first test from the browser.
• Slack: invite the bot to a channel to list scripts, review source, switch Nexus specialists, and approve runs. See the Slack guide.

Export generated tests

From a project’s Test Cases view, choose Export generated tests to select the supported generated scripts and prepare a portable ZIP. Downloads work without a connected repository and are intentionally marked not validated. The export manifest lists every selected script, its runtime, and an explicit reason when a script cannot be exported.

The current portable bundle supports Playwright JavaScript/TypeScript and pytest Python tests. Run it locally with the generated README: install the bundle’s declared dependencies, then use npx playwright test for Playwright or pytest for pytest. The bundle includes a GitHub Actions v1 workflow; review its input names and supply repository secrets through GitHub Actions. Values entered for a repository candidate validation are sent only for that request and are not stored in the export session.

To create a draft PR, choose a connected repository, then review the exact branch and full commit SHA. QualityMax verifies that checkout, previews additive files and conflicts, and shows existing dependencies, repository configuration, monorepo package paths, services, and working directories before candidate validation. Runtime and environment input names come from the generated manifest; QualityMax does not invent endpoint defaults. A successful candidate validation is required before publishing a draft, and the final PR head and required-check evidence remain visible in the export flow. Reporting remains optional: use your existing JUnit, HTML, or artifact reporting configuration. Cypress and k6 exports are shown as unsupported with their reason. GitLab repository imports and test execution remain available through their existing integration paths; the draft workflow currently requires a GitHub App repository connection.

Slack test actions

This section is the command contract for Slack test actions. For setup, permissions, Nexus switching, healing limits, and troubleshooting, use the Slack guide.

In Settings → Integrations → Slack, connect the workspace and invite the bot to a channel; everything is enabled from there, and Manage is where you narrow it. Link your QualityMax account to act. Enabling run_tests allows run proposals even when automatic notifications are disabled. Project membership, the channel policy, and current action permissions are checked again when you approve.

• list these scripts lists current authorized script IDs and exact run commands.
• run script 42 prepares a run for that script. run test case 7 selects its linked scripts.
• run scripts from 290 selects that project’s scripts in its linked channel, up to 20 per approval. Larger selections require explicit script IDs; they are never silently truncated.
• can you try again to run?, run scripts now, and try to run scripts now resolve a recent user selection using fresh records and access.
• Bare run? does not reuse a selection. Specify a target or refer to the selection with run them or run again.
• After listing scripts, run #42 can select that ID when its record type is unambiguous in the current selection. Otherwise, specify script or test case explicitly.
• A copied script label after a numeric ID is treated only as a consistency hint. The current authorized record, project ownership, runner, and source version determine the proposal.

Every run requires approval of the exact targets and versions. Enabling an action permission does not approve a run. A model asking “shall I proceed?” does not create an executable proposal. QualityMax posts execution evidence after an approved action runs; Nexus personas do not need to hand the request to another specialist. Script edits and healing use their own permissions and review steps.

You can paste a whole command as Slack inline code, a code block, or bold text. qmax test run --script-id 42 --wait also prepares the same Slack run proposal; Slack does not run arbitrary terminal commands or extra CLI flags. Use Approve on the proposal card and complete any confirmation dialog it opens. For a run or healing proposal addressed to you, you can instead reply yes, run, ok, agree, I agree, or proceed immediately in the same thread. Ordinary capitalization and terminal punctuation are accepted. This approves the exact pending action only when the posted proposal and your reply have verified Slack delivery timestamps, no conversation turn intervenes, and one unexpired compatible proposal is pending for you. Other acknowledgments, ambiguous selections, or missing delivery evidence require the card. A failed or uncertain bot delivery can disable text approvals in that thread; use the explicit card controls or start a fresh thread.

Approval is stored before the action is sent to a worker. If that queue publication is interrupted, QualityMax keeps the approved action pending and retries it. Repeated worker deliveries cannot execute the same proposal twice because the worker must atomically claim the still-approved proposal before starting it.

For a script edit, use update script #42 replace "old text" with "new text". The card previews the exact change against the current script version. Code inside the replacement strings is preserved, including backticks and asterisks. After an approved Slack run fails, ask heal this script or repair the latest failure in the same thread. QualityMax resolves only the failed execution receipts written by that completed run, checks current access, and posts an approval to analyze the evidence and generate a patch. This first approval does not edit the script. When generation succeeds, QualityMax posts a separate proposal containing the bounded failure classification, healing strategy, validation score, and diff statistics. Approving that second proposal applies the exact patch only while its script, failure, actor, channel, permissions, and source versions still match. Existing failed-run incident threads continue to support their scoped healing flow.

QualityMax resolves explicit action commands with deterministic parsers first. A constrained, lightweight language-model classifier can map ambiguous requests to a small allowlist of intent labels. The model cannot choose tools, record IDs, action arguments, or approvals; durable Slack and database records determine those values before a proposal is created.

Script inventory lists show script names to authorized Slack users with scripts Data access. Use descriptive names without credentials or confidential identifiers. Known secret patterns are redacted, but arbitrary sensitive names cannot be recognized reliably.