qa

A command that sends a browser task to the qa-tester agent for verification. QA means checking whether software behaves as expected.

In plain words
What is it for?
Use it for regression checks, smoke tests, and single browser tasks with a pass-or-fail outcome. It also supports exhaustive checks of every actionable control.
Why use it?
It separates browser testing from implementation work and returns a clear result with evidence, or explains why the task cannot be tested as given.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/devzonayed/mochi/qa
Clone the repo
git clone --depth 1 https://github.com/DevZonayed/Mochi
Per session 49 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,911 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00049 $0.01911
Opus 5 $0.00024 $0.00955
Sonnet 5 $0.00010 $0.00382
Haiku 4.5 $0.00005 $0.00191

Measured yesterday against content hash dc3a9be40031, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

qa scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/qa/commands/qa.md · 92 lines

How it starts

The opening of the file, as written. The whole thing — 92 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Mode select

Inspect $ARGUMENTS and pick ONE mode:

  • EXHAUSTIVE mode — choose this when $ARGUMENTS begins with exhaustive, contains --exhaustive, or contains intent phrases like "test everything", "click every button", "make everything dynamic / nothing static", or "exhaustive QA". Follow the Exhaustive QA mode section below.
  • Single-dispatch mode (default) — everything else. Follow the Single dispatch section below.

Single dispatch

Dispatch the qa-tester subagent with the user's task: $ARGUMENTS

Use the Task (Agent) tool with subagent_type: "qa-tester" and pass the user's task verbatim as the prompt. If the task is clearly ambiguous (no clean pass/fail outcome) explain why and ask the user to clarify before dispatching.

After the subagent returns its verdict, surface a short summary to the user:

  • On pass: "✓ Task passed via playbook <id> (run <id>). Evidence: <screenshots/network summary>."
  • On fail: "✗ Task failed: <reason>. Evidence: <…>. Suggest re-running with adjusted inputs."
  • On blocked: "Cannot run as-is: <reason>. Need: ."

Exhaustive QA mode

GOAL: verify EVERY actionable control on the target app — not "the page renders", but "each control was exercised and we observed what it did". The five verdicts you assign each control are WORKS, NO-OP (defect), ERROR (defect), NAVIGATES, DISABLED. Render != Works. A clickable control that does nothing is a NO-OP — a defect, not a pass.

Pick a short <app> slug (e.g. the host/feature, used for the ledger) and the base URL from $ARGUMENTS. Then run this coverage-driven loop. You MAY parallelize by spawning the qa-tester subagent per (role × route) and merging the partial coverage matrices each returns; but the honesty gate below is run ONCE at the end over the merged ledger.

1. PRE-FLIGHT — confirm you are testing the right build

  • browser_navigate { url, hardReload: true } — cache-bypass load so you are not testing a stale bundle.
  • browser_page_assets { hash: true } — capture the LIVE bundle hash(es). If you know the built hash, confirm live == built (stale-bundle guard). Note: browser_emulate_viewport changes JS layout (window.innerWidth / matchMedia via CDP device metrics); browser_window_resize only moves the OS window and does NOT affect JS layout — use browser_emulate_viewport for breakpoint coverage.
  • browser_assert_no_errors { sinceNavigation: true } immediately after load. Treat any pre-existing console buffer as UNTRUSTED — sinceNavigation:true scopes to the current page so you do not get a false "no errors" from stale buffers.

Read the full file on GitHub · 92 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 92 lines · 49 tokens per session scan A dc3a9be40031

Subscribe to this mod's changes

qa is a command published in the GitHub repository DevZonayed/Mochi (3 stars, last pushed 15d ago), licensed MIT. It adds 49 tokens to every session and 1,911 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.