/agent-qa

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select agent-qa from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv agent-qa, /just-vibe agent-qa and /jv:agent-qa in Claude. See shortcut setup and context examples.

What the agent does

1. Read the original request before implementation details. Translate each requested visitor outcome into observable acceptance criteria, quoting the relevant request text. Include successful completion, an invalid-input path and the requested viewport. Separate subjective design judgments from assertions. Do not silently treat inferred criteria as user requirements; mark assumptions in criterion text. Record a reviewed request-to-criterion coverage map with explicit uncovered reasons. Unreviewed or uncovered requirements prevent a complete acceptance claim even when assertions pass.
2. Read the Agent QA guide. Discover browser tools and inspect the app to select actual controls; never invent selectors. Prefer the bounded QA runtime when the target project already has Playwright and Chromium; otherwise use available host browser tools with proof records. Missing tools, authentication, fixture data or a running server make dependent checks blocked, not passed.
3. Create a QA plan with exact target, request-linked criteria, viewport and ordered actions/assertions. For an upload, assert processing completion and advancing media playback, not merely the existence of an upload element. For invalid files, assert visible understandable error content. For mobile, check horizontal overflow, specified control clipping and overlap; retain a screenshot for human visual review. Declare required additional origins; obtain explicit per-run authorization for them and any private test-account storage state. Mask identified private UI in screenshots; never persist passwords in steps.
4. Run verification in a fresh browser context against the authorized target. Prefer a separate verifier only when delegation is permitted; otherwise label this self-review with independent executable assertions. Do not describe running tests in the implementation session as an independent agent review. Keep code inspection and browser results separate.
5. When a check fails, preserve the actual/expected result, viewport, target URL, failed step, screenshot and reproduction sequence. Verify that it is a product defect rather than a missing prerequisite. If repairs are authorized, fix the smallest relevant cause and rerun the same criteria within the configured attempt budget. Never delete the first failure or weaken a criterion to turn the report green. Keep network restrictions separate from assertion failures: an unrelated blocked request must not erase a failure.
6. Recompute evidence freshness and produce the report including all attempts. Disclose unchecked request clauses, subjective judgments, blocked environments and source/build identity uncertainty. Stop on the attempt limit and report remaining work. A successful fixture run or isolated browser assertion cannot prove the entire app is correct. Offer an export of fresh, passing, reviewed journeys as runnable project regression tests, without credentials; do not export stale or incomplete acceptance as passing.

Inputs

• Original request and the authorized target app URL; identify any missing fixture or acceptance ambiguity before the dependent check.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Original user request, relevant source and fixtures, running target app, prior QA attempts and screenshots.

Writes

Create local QA plans, isolated browser sessions and evidence artifacts. Interact only with the authorized target using synthetic fixtures. Fix product code only when the user has authorized repairs; do not submit purchases, publish, delete real data or upload private recordings.

Mode

Apply runs the requested browser verification and records local evidence. Inspect derives criteria and examines existing evidence without interacting with the target.

Prerequisites

Defined behavior, existing test conventions/runners, isolated fixtures, and relevant dependencies. Requested bounded verification may use owned isolated fixtures without authorizing product edits or live-system tests. Never test destructive behavior against production by default; distinguish mocked behavior from real integration evidence.

Expected output

• Request-linked acceptance plan with explicit assumptions and human-only criteria.
• Browser assertion results, screenshots, failure reproduction steps and complete retest history.
• Current evidence freshness and remaining limitations.

How the work is checked

• A broken processing flow must fail even when the upload control is visible.
• Changed source or modified screenshots invalidate previously passing evidence.
• Unavailable browser dependencies remain blocked; subjective criteria remain needs-human.
• Redirects never contact an unapproved origin; allowed API origins require explicit authorization.
• A clipped ancestor must fail layout verification, and an unrelated blocked request must not mask a failed assertion.

When to stop or clarify

• Stop at the attempt budget; do not weaken expectations or erase failures.
• Do not interact with unapproved production data or claim remote build identity from local source hashes.

Handling missing context

Infer

Read behavior contracts, existing runners and test conventions; distinguish fixture setup failure from a behavioral failure.

Assume

Use the smallest existing local runner and isolated synthetic fixtures that distinguish the requested behavior. When the method needs a library, runner, container runtime or load tool the project lacks, name the exact package or tool, the files it changes and any download, and add it only when the request authorizes new dev dependencies or tools; label a hand-written generator without shrinking, or a fake in place of a real dependency, as such.

Ask

Ask about an unresolved contract that changes the expected result, or the target/load limits before external testing; do not ask the user to choose a runner already configured.

Technical guidance

Evidence

Original request quotes, observed controls, synthetic fixtures, target URL, source snapshot, failed step and hashed screenshots.

Method

Use bounded executable browser actions and assertions in fresh contexts; retain every attempt and compare evidence identities after repairs.

Pitfall

Component presence, HTTP success or a screenshot alone does not establish a successful visitor journey. Remote servers may serve a different revision.

Check

Exercise the failing flow and, after an authorized repair, retest it against the same criteria; preserve failures, flag changed evidence, and leave subjective or unavailable checks unresolved.

Situational decisions

When a required check is unavailable or fails before exercising behavior: Mark that criterion unverified and report the prerequisite separately from product failure.

When automated behavior is correct but a subjective criterion is unresolved: Report the automated evidence and leave human acceptance pending rather than manufacturing a pass.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring