arthai-marketplace

Quality Assurance Guide

The arthai QA framework uses a four-layer test strategy with 9 specialized agents.

Four-Layer Test Strategy

Every QA run uses four complementary layers:

1. Baseline Tests — existing test suites (regression anchor, same every run)
2. Generated Scenarios — fresh every run, thinks like real users based on the diff
3. Property-Based Tests — infer invariants from code changes, test with random/edge-case inputs
4. Coverage Audit — reviews if existing tests still match the codebase

Modes

Mode	Command	What it does	Time
Commit	/qa or /qa commit	Targeted checks on changed files, 2-4 agents	~1-3 min
Full	/qa full	All checks across full codebase, all agents	~10-20 min
Staging	/qa staging	Health + smoke + E2E against deployed staging	a few min
Production	/qa prod	Read-only health + smoke (NO mutations)	a few min
E2E Gen	/qa e2e-gen	Generate Playwright tests for changed components (opt-in)	~3-8 min
Visual	/qa visual	Computer-use visual regression at desktop + mobile (opt-in)	~5-15 min

QA Agents

Agent	Model	Role
qa-baseline-updater	sonnet	QA baseline updater — manages test snapshots and golden files for API response v
qa-challenger	sonnet	Adversarial QA agent that red-teams test plans. Reads the diff, knowledge base,
qa-domain	sonnet	Domain logic quality evaluator. Validates business logic integrity — state machi
qa-e2e-gen	sonnet	Generates exploratory Playwright tests from git diffs. Maps changed components t
qa-e2e	sonnet	E2E test specialist — Playwright browser tests for user workflows, axe-core a11y
qa-ios	sonnet	iOS simulator-based visual QA via xcrun simctl + computer-use MCP. Boots iPhone
qa-test-promoter	haiku	Converts generated test scenarios that caught real bugs into permanent baseline
qa-visual	sonnet	Visual regression QA using computer-use MCP (screenshots) and claude-in-chrome (
qa	sonnet	QA orchestrator — testing across backend, frontend, and E2E layers

Typical Workflow

During development:

/qa                     # quick check on changed files
/qa e2e-gen             # generate E2E tests for UI changes (opt-in)
/qa visual              # visual regression check (opt-in, needs dev server)

Before shipping:

/qa full                # comprehensive check across all files
/precheck               # local CI in 30s
/pr                     # create PR with QA results

After deployment:

/qa staging             # validate staging deployment
/qa prod                # read-only production health check

Related Skills

Skill	Usage	Description
/ci-fix	/ci-fix [ci|staging|prod] [branch]	Auto-remediate CI, staging, and production failures. 3-attem
/fix	/fix <description|#issue> <--severity critical|high|medium|low> <--hotfix|--lite|--lite-strict|--verified|--full|--swarm>	Formal bug fix pipeline — root cause analysis, scope lock, b
/qa	/qa (commit), /qa full (comprehensive), /qa staging (deployed), /qa prod (read-only), /qa e2e-gen (opt-in), /qa visual (opt-in). Flags: <--commit-strict> <--workflow|--classic> <--invoked-by VALUE>	Run QA checks.
/qa-incident	/qa-incident <description>	Manually create a QA incident from a known issue.
/qa-learn	/qa-learn [prune]	Review QA knowledge base stats, prune stale entries, show le

QA Knowledge Base

The QA system learns from past runs:

• qa-knowledge/bug-patterns.md — patterns that caught real bugs
• qa-knowledge/coverage-gaps.md — persistent test gaps
• qa-knowledge/flaky-tests.md — tests that pass/fail inconsistently
• qa-knowledge/incidents/ — past incidents in affected files

Use /qa-learn to review stats and prune stale entries.

Installing QA

The prism bundle includes the full QA suite:

/plugin install prism@arthai

Or get everything with prime:

/plugin install prime@arthai

Auto-generated on 2026-07-16