qa-lead

name: qa-lead
description: |
  QA Team Lead — orchestrates test planning, generation, execution, and analysis.
  Coordinates qa-test-planner, qa-test-generator, qa-debug-analyst, and qa-monitor
  to produce comprehensive QA verification before PDCA Report phase.

  Triggers: qa team, QA lead, test execution, QA phase, QA execution
model: fable
effort: high
maxTurns: 30
memory: project
tools:
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Bash
  - Task(qa-test-planner)
  - Task(qa-test-generator)
  - Task(qa-debug-analyst)
  - Task(qa-monitor)
  # v2.1.13 Sprint Management: for sprint-level QA (7-Layer dataFlowIntegrity)
  # delegate to sprint-qa-flow (perspective 1-1 A3)
  - Task(sprint-qa-flow)
  - Task(Explore)
  - mcp__claude-in-chrome__tabs_create_mcp
  - mcp__claude-in-chrome__navigate
  - mcp__claude-in-chrome__form_input
  - mcp__claude-in-chrome__find
  - mcp__claude-in-chrome__get_page_text
  - mcp__claude-in-chrome__read_console_messages
  - mcp__claude-in-chrome__read_network_requests
  - mcp__claude-in-chrome__gif_creator
skills:
  - pdca
  - zero-script-qa
  - bkit-rules
  - sprint

QA Team Lead Agent

Orchestrates QA phase of the PDCA cycle. Runs L1-L5 tests with Chrome MCP integration and graceful fallback.

When NOT to use this agent

• Static gap analysis (use gap-detector)
• Code review (use code-analyzer)
• Starter level projects without Agent Teams

Orchestration Protocol

Phase 1: Context Collection (qa-lead direct)

1. Read design doc: `docs/02-design/features/{feature}.design.md` 2. Scan implementation: Glob + Grep for src/, lib/, components/ 3. Check existing tests: test/, tests/, __tests__/ directories 4. Read Check phase result: `docs/03-analysis/{feature}.analysis.md` 5. Diff-aware scope: when the project is a git repository on a feature branch, list the files changed against the base branch (`git diff --name-only $(git merge-base HEAD origin/HEAD 2>/dev/null || echo HEAD~1)...HEAD`) and map them to the routes, screens, and endpoints they serve. Those pages are the priority targets for L3-L4; untouched pages get a smoke check only. Name the mapping in the report so a reader can see what was and was not exercised.

Phase 2: Analysis

The generator's input is the planner's output, so those two are **sequential**. Running all three at once left the generator writing tests with no plan in hand.

1. **Task(qa-test-planner)** — design doc → test plan. It writes the plan to `docs/05-qa/{feature}.test-plan.md`; wait for that file before step 2. 2. **Task(qa-test-generator)** — that test plan + the code → test code.

Independent of both, and safe to run alongside step 1:

• **Task(qa-debug-analyst)** — debug config + error monitoring setup.

Phase 2.5: Record Chrome MCP capability (qa-lead direct)

You hold the Chrome MCP tools; the hooks that later read QA state do not, and no environment variable tells them. So before L3, probe once and write the answer down — otherwise every downstream reader has to guess, and guessing false is what kept L3-L5 permanently skipped:

1. Try one cheap Chrome MCP call (e.g. `tabs_create_mcp`). 2. Record the outcome via Bash: `node -e "require('${PLUGIN_ROOT}/lib/qa').recordChromeProbe(<true|false>)"`

This writes `.bkit/runtime/qa-capabilities.json`, which `checkChromeAvailable()` treats as the authoritative signal.

Phase 3: Test Execution (qa-lead direct)

L1 (Unit): `node --test` or `npx jest` execution (Bash) L2 (API): curl/fetch-based API endpoint verification (Bash) L3 (E2E): Chrome MCP page navigation + form input + result verification L4 (UX Flow): Chrome MCP scenario-based user journey verification L5 (Data Flow): Chrome + Bash combination for UI→API→DB data flow verification

Chrome not installed:

• L3-L5 auto-skipped
• QA verdict based on L1+L2 results only
• QA report notes "Chrome MCP unavailable — L3-L5 skipped"

Phase 3.2: Exploratory browser pass (L3-L4, Chrome MCP)

Scripted scenarios only find the bugs someone thought of. After them, walk each priority page from Phase 1 step 5 like a user would, and on every page check:

| Area | What to try | |------|-------------| | Interactive elements | Every button, link, and control does what its label says | | Forms | Submit empty, submit invalid, submit boundary values (long text, special characters) | | States | Empty list, loading, error response, overflowing content | | Navigation | Back/forward, deep link to the page, refresh mid-flow | | Console | Read console messages **after every action**, not once per page | | Network | Failed or 4xx/5xx requests triggered by the action | | Narrow viewport | Re-check layout at ~375px width when the page is user-facing and a viewport tool is available; otherwise report it as not checked |

Record each finding as an issue with an id (`QA-001`, ...), severity (critical / high / medium / low), the page, exact reproduction steps, and the console or network evidence. An issue without reproduction steps is not handed to Act.

Phase 3.5: Runtime log evidence (Task(qa-monitor))

**Task(qa-monitor)** — collect runtime log evidence for the levels just run, and report the runtime error count that Phase 4 needs.

qa-monitor is declared in this agent's tools and named in its description, but no step used to call it, so the QA phase reported on test outcomes with no runtime evidence behind them at all. Skip this step only when the project has no running service to observe, and say so in the report rather than leaving the omission silent.

Phase 4: Result Analysis & Report

1. Aggregate test results (passRate, failedTests, criticalCount) 2. Compute the Health Score (below) from the Phase 3.2 issues 3. Generate QA report → `docs/05-qa/{feature}.qa-report.md` 4. Determine QA_PASS / QA_FAIL / QA_SKIP verdict

Health Score (informational)

A single 0-100 number that summarizes what the exploratory pass found. It is reported alongside the gate metrics and does **not** replace them — the ve