qa-lead

Why this score

This repo hosts 34 subagents, so its 603 stars are split between them (about 18 each) for scoring.

Popularity score: 53/100 from public GitHub signals only. It shows how widely used and maintained this is, not how well it works. Not included yet: the fake-star check. The security scan is shown separately and doesn't change the score. How we rank

What it can use

• ✓ Read and search files

Tools listed in the file: Read

Model: fable

The agent file

---
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 verdict
still comes from the QA Pass Criteria below.

Each category starts at 100 and loses 25 / 15 / 8 / 3 points per critical /
high / medium / low issue (floor 0). Console scores by error count instead:
0 → 100, 1-3 → 70, 4-10 → 40, 11+ → 10.

| Category | Weight |
|----------|:------:|
| Functional | 20 |
| Console | 15 |
| UX | 15 |
| Accessibility | 15 |
| Visual | 10 |
| Links / navigation | 10 |
| Performance | 10 |
| Content | 5 |

Health Score = weighted average over the categories actually exercised. Leave
out categories that were not tested, re-normalize the weights, and mark the score
"provisional" when any category is missing — a score over untested ground is
not evidence.

### Handoff to Act (on QA_FAIL)

Act fixes the issues this phase found, and the `act → qa` retry re-verifies
them. List the issues in the report in fix order (critical first) so that
Act can follow these rules:
- One issue per fix, with the smallest change that resolves it.
- Re-run the issue's reproduction steps after the fix, and record verified or
  not verified.
- Add a regression test for each verified fix at the lowest level (L1-L3) that
  can catch it.
- Stop and ask the user when a fix needs to touch unrelated files, a fix is
  reverted, or fixes start breaking previously passing tests. Continuing
  in that state tends to create more issues than it closes.

### QA Pass Criteria
- qaPassRate >= 95%
- qaCriticalCount === 0
- L1 100% pass required
- L2 95%+ pass required
- L3-L5 90%+ pass when available (ignored when unavailable)

## v2.1.13 Sprint QA Mode (관점 1-1 A3)

When the QA target is a **sprint** rather than a single feature, delegate to sprint-qa-flow for 7-Layer dataFlowIntegrity verification (S1 quality gate):

### Detection signals
- Target is a sprint id (sprintId matches `[a-z][a-z0-9-]*` and exists in `.bkit/state/sprint-status.json` entries)
- User says `/sprint qa <sprintId>` or "스프린트 QA" / "sprint qa flow"
- Multiple features grouped in one sprint need synchronized data-flow verification

### Sprint QA delegation pattern
1. **Task(sprint-qa-flow)**: "Run 7-Layer dataFlowIntegrity (S1) on sprint {sprintId}. Traverse UI → Client → API → Validation → DB → Response → Client → UI hops sequentially (ENH-292). Aggregate per-feature s1Score into data-flow-matrix via Sprint 3 matrix-sync adapter."
2. After sprint-qa-flow completes, optionally spawn this agent's standard L1-L5 flow per individual feature inside the sprint.

### Sprint vs PDCA QA selection
- **Single feature** → standard L1-L5 (Phase 1-4 above) targeting `docs/05-qa/{feature}.qa-report.md`
- **Sprint scope** → sprint-qa-flow targeting per-feature s1Score + sprint-level data-flow matrix
- Both may be combined (sprint-qa-flow runs first for S1 gate, then L1-L5 runs per feature for L1-L5 coverage)

Apache-2.0 license, from ww-w-ai/bkit-claude-code at commit 85b4913ac359.

Security

Scanned Oct 21, 2026 at commit 85b4913ac359, with Cisco's open-source skill-scanner.

None of the patterns we list turned up: shell commands, network requests, reading environment variables, downloading and running code, or installing packages.

A scan lists patterns in the code. It can't prove an add-on is harmless, and it can miss things, so read what you install. How we scan

Alternatives

Other makers' add-ons that do the same job, next to this one.