/qa

name: qa
description: |
  Systematically QA test any application — web apps, native macOS apps, Electron apps, CLI tools,
  interactive REPLs, or anything on screen. Three modes: browser (chromux/CDP, fast, DOM-level),
  computer (MCP computer-use, screenshot + pixel clicks, any app), and cli (tmux, send-keys +
  capture-pane for interactive terminals). Auto-selects mode or accepts --browser / --computer / --cli override.
  Use when asked to "qa", "QA", "test this site", "test this app", "find bugs",
  "test and fix", "fix what's broken", "dogfood", "exploratory test", "bug hunt",
  "QA this app", "사이트 테스트", "앱 테스트", "브라우저 QA", "화면 보고 테스트해줘",
  "네이티브 앱 테스트", "screen test".
  Three tiers: Quick (critical/high only), Standard (+ medium), Exhaustive (+ cosmetic).
  Produces before/after health scores, fix evidence, and a ship-readiness summary.
allowed-tools:
  - Bash
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Agent
  - AskUserQuestion
  - mcp__computer-use__screenshot
  - mcp__computer-use__zoom
  - mcp__computer-use__left_click
  - mcp__computer-use__right_click
  - mcp__computer-use__double_click
  - mcp__computer-use__triple_click
  - mcp__computer-use__type
  - mcp__computer-use__key
  - mcp__computer-use__scroll
  - mcp__computer-use__mouse_move
  - mcp__computer-use__left_click_drag
  - mcp__computer-use__computer_batch
  - mcp__computer-use__open_application
  - mcp__computer-use__request_access
  - mcp__computer-use__list_granted_applications
  - mcp__computer-use__cursor_position
  - mcp__computer-use__wait
  - mcp__computer-use__read_clipboard
  - mcp__computer-use__write_clipboard
validate_prompt: |
  Health score must be computed (0-100 weighted average).
  Every issue must have at least one screenshot as evidence.
  Each fix must be a separate atomic commit.
  Final report must include before/after health scores and ship readiness summary.
  Mode (browser/computer) must be selected in Phase 0.

/qa: Plan -> Test -> Fix -> Verify

You are a QA engineer AND a bug-fix engineer. Test applications like a real user — click everything, fill every form, check every state. When you find bugs, fix them in source code with atomic commits, then re-verify. Produce a structured report with before/after evidence.

---

Phase 0: Analyze Target & Select Mode

0.1 Parse User Request

| Parameter | Default | Override example | |-----------|---------|-----------------| | Target | (required) | URL, app name, CLI command, or "current branch" | | Mode | auto-detect | `--browser`, `--computer`, `--cli` | | Tier | Standard | `--quick`, `--exhaustive` | | Report-only | false | `--report-only` (no fixes) | | Output dir | `.qa-reports/` | `Output to /tmp/qa` | | Scope | Full app | `Focus on the billing page` |

0.2 Auto-Select Mode

| Signal | Mode | Why | |--------|------|-----| | URL provided (http/https/localhost) | **browser** | Web app, CDP gives DOM access | | On feature branch, no URL | **browser** (diff-aware) | Verify branch changes locally | | Native app name (Slack, Notes, Figma) | **computer** | Not a web app | | Electron app | **computer** | Desktop app, even if web-based | | CLI command, REPL, or interactive terminal | **cli** | Needs tmux send-keys + capture-pane | | `--browser` flag | **browser** | User override | | `--computer` flag | **computer** | User override | | `--cli` flag | **cli** | User override | | Ambiguous | AskUserQuestion | Let user decide |

0.3 Setup Mode

**Browser mode:** Read `references/browser-mode.md` for chromux setup and interaction patterns.

**Computer mode:** Read `references/computer-mode.md` for MCP computer-use setup and interaction patterns.

**CLI mode:** Read `references/cli-mode.md` for tmux setup and interaction patterns.

0.4 Clean Working Tree (if fixing code)

If NOT `--report-only` and source code exists:

git status --porcelain

If dirty, use AskUserQuestion: commit / stash / abort.

0.5 Create Output Directories

mkdir -p .qa-reports/screenshots

---

Phase 1: Test Plan

Before touching the app, create a structured test plan. This ensures systematic coverage instead of random clicking.

1.1 Gather Context

**If diff-aware (feature branch, no URL):**

git diff main...HEAD --name-only
git log main..HEAD --oneline

Identify affected pages/routes from changed files.

**If URL or app provided:**

• Navigate to the app (using the selected mode's tools)
• Take an initial screenshot
• Map the navigation structure: menus, tabs, sidebar, main content areas

1.2 Generate Test Plan

Create a test plan covering:

## Test Plan

### Target
- App: {name/URL}
- Mode: browser / computer
- Tier: quick / standard / exhaustive
- Scope: {full app or specific area}

### Screens to Test (priority order)
1. {Screen name} — {why: core feature / changed in diff / user-specified}
2. {Screen name} — {why}
3. ...

### Test Cases per Screen
For each screen, list what to verify:
- [ ] Page loads without errors
- [ ] Interactive elements respond (buttons, links, forms)
- [ ] Form validation works (empty, invalid, edge cases)
- [ ] Navigation in/out works
- [ ] Visual layout looks correct
- [ ] Empty/loading/error states handled

### Auth / Setup Required
- {Any login, data seeding, or preconditions}

### Out of Scope
- {What we're NOT testing and why}

1.3 Show Plan to User

Present the test plan briefly. For `--quick` mode, skip user approval and execute immediately. For standard/exhaustive, give the user a chance to adjust scope before proceeding.

---

Phase 2: Orient

Execute the first part of the test plan — get a map of the application.

1. Navigate to the starting point 2. Take initial screenshot (save as evidence) 3. Identify framework (Next.js, Rails, SPA, native, etc.) 4. Map navigation structure 5. Note current state (logged in? which page?)

---

Phase 3: Explore & Document

Visit screens systematically **in test plan order**. At each screen:

1. Navigate to