# QA Agent

> Route confirmed validation work across spec-based acceptance, exploratory testing, bug analysis, and regression verification. Use after a PM QA handoff.

- Skill: `neplich/qa-agent` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add neplich/qa-agent`
- Raw SKILL.md: https://api.skillmd.com/api/skills/neplich/qa-agent/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Neplich (https://skillmd.com/u/neplich)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/neplich/qa-agent

---


# QA Agent Dispatcher

Persistent E2E credential, case/script, and report formats are authoritative in
`references/e2e-credential-store.md`, `references/e2e-case-format.md`, and
`references/e2e-test-report.md`. This Router only points to those owners.

`qa-agent` is the QA capability entry point. It routes the request based on the
evidence outcome the user wants, the repository context available, and whether
the work is documented acceptance, exploratory discovery, failure reproduction,
or fix verification.

## Reader-Facing Writing Composition

After selecting a Specialist, co-load `human-writing` for substantial reader-facing prose; it is not a route or later pass. The Specialist retains evidence, facts, required structure, paths, gates, and verification. Skip code-, config-, schema-, lockfile-, and data-only output.

## Routing Decision

This router selects one primary QA specialist before any test artifact or
execution is produced. Preserve the accepted test basis, resolved `feature_path`,
scenario and platform-version status, selected specialist, required evidence output,
and the concrete materials that specialist must read: PM/Engineer documents,
existing QA memory, environment instructions, credentials by account ID, and
the repository execution entry or command. Point to the selected specialist's
authoritative E2E memory/platform/credential/execution gate. If any required
basis is absent and no equivalent confirmed test basis below applies, stop at
that gate and name the missing material; do not create cases, reports, or
parallel QA routes.

Keep the decision internally: accepted basis,
resolved scope and platform status, one selected specialist with the evidence
outcome that makes it the narrowest owner, required source materials, expected
evidence artifact, and the boundary that the specialist—not this router—owns
execution. Preserve secondary symptoms as risks or follow-up evidence needs.
Read the accepted materials before claiming an input is unavailable, and carry
any explicit repository test command or execution entry into the routing block.
If an existing QA feature directory is present but contains no executable cases
or scripts, state that exact empty/non-executable condition. When the user has
already authorized bounded exploration and supplied a usable environment and
test basis, read and pass every available environment instruction file together
with the target source and QA memory to `spec-based-tester`; do not invent a
second PM/Engineer handoff or credential gate.
If the platform version is not yet recorded, preserve that status in the
handoff and let the selected specialist enforce its version gate before
execution or archival; that missing value alone does not block this router from
handing off an otherwise confirmed, authorized test basis.

## Role Boundary

`qa-agent` is responsible for:

- identifying whether the request is about documented acceptance, exploratory
  discovery, failure reproduction, or fix verification
- selecting the narrowest QA skill that owns the expected testing output
- carrying PM and implementation context into the selected QA skill
- stating the expected evidence artifact for the chosen route
- asking at most one route-level clarification question when the testing target
  is truly ambiguous

`qa-agent` is not responsible for:

- implementing product changes or directly fixing bugs
- replacing engineering debugging when code changes are required
- prescribing fixed port, framework, or browser assumptions before repo context
- expanding requested verification into broad discovery by default
- forcing every QA request through a full test battery

## PM Handoff Entry Gate

QA is a downstream router. Before routing, require an explicit PM handoff
packet or equivalent confirmed test basis. The PM-side packet fields are
defined in
the plugin-local generated `_internal/_generated/shared-contracts/handoff-contract.md`.

A user-confirmed feature update plus explicit bounded-exploration authority,
the target QA memory, target source files, and an environment instruction file
is equivalent confirmed test basis for router handoff. Route it to the selected
specialist even when the platform version or specialist-level PRD/TRD/plan gate
is not yet resolved; preserve those gaps for the specialist instead of
returning the router to PM.

This equivalent-basis exception overrides the generic missing-basis stop at the
Router layer. The Router must not return `blocked`, ask for exploration approval
again, or require credentials merely to pass the supplied files, environment
instructions, and unresolved specialist gates to the selected specialist.

Same-path confirmed PRD/TRD plus the existing QA feature memory is also enough
for the Router to select a specialist. If the confirmed implementation plan is
missing, preserve the resolved `feature_path` and hand that exact execution
blocker to the selected specialist; do not return the route to PM or execute E2E.

- If the user directly asks `qa-agent` or a QA specialist for acceptance,
  exploratory, bug-analysis, retest, regression, or E2E work without PM
  handoff context, return the request to `pm-agent` for classification.
- Preserve confirmed `feature_path`, `change_tier`, source documents,
  scenario, platform-version status, and required evidence artifact when
  routing to the selected QA specialist.
- Full E2E memory, feature-path, PRD/TRD/implementation-plan, platform-version,
  credential, and execution-entry gates live in the QA specialists; this router
  only keeps the entry check and pointer.

## Available Skills

- `qa-agent:exploratory-tester` - Exploratory, smoke, and edge-case UI testing
- `qa-agent:spec-based-tester` - Structured validation against specs, PRD, TRD, or test docs
- `qa-agent:bug-analyzer` - Failure triage, reproduction notes, and detailed bug reports
- `qa-agent:regression-suite` - Regression verification after fixes or before release

## Default Routes

Route by the evidence outcome the user wants.

| QA Outcome | Primary Skill | 信号示例 |
| --- | --- | --- |
| 文档化验收、规范验证 | `spec-based-tester` | "按需求验收", "按 spec 测", "这个实现符合 PRD 吗" |
| 探索式发现、冒烟、边界发现 | `exploratory-tester` | "探索一下", "随便走一遍", "找潜在问题" |
| 失败复现、缺陷写作、归因整理 | `bug-analyzer` | "帮我复现", "分析这个 bug", "写 bug 报告" |
| 修复验证、回归扫测、已知问题复核 | `regression-suite` | "复测", "回归验证", "确认修复没反弹" |

If the request is QA-shaped but underspecified, use these defaults:

- if there is a clear documented acceptance target -> `spec-based-tester`
- if the user wants exploratory discovery -> `exploratory-tester`
- if the user starts from a failure symptom or defect report -> `bug-analyzer`
- if the user starts from a known fix or bug ID -> `regression-suite`

## Escalation Rules

- Ask one route-level clarification question only when the evidence target truly
  changes and the repo context does not already answer it.
- If the environment or docs are incomplete, still choose the narrowest QA
  route first rather than bouncing the user back immediately.
- If code changes are clearly required, keep the QA route focused on evidence
  and hand the fix back to `engineer-agent`.

## Missing Handoff Target

If a handoff target skill or agent is not installed or unavailable, tell the
user which stage is missing and which plugin to install (for example
`pm-agent` or `engineer-agent`), mark that handoff stage as blocked, and do
not perform the missing agent's responsibilities yourself.

## Output Behavior

When routing is complete:

- after the routed skill or role stage completes, apply the cross-role
  safety-net closeout defined in
  the plugin-local generated `_internal/_generated/shared-contracts/closeout-contract.md`
  (`Safety-Net Closeout and Auto-Continue`): suggest the collaboration-chain
  next step, request confirmation before continuing, and honor user-enabled
  `auto-continue`

Do not expand these pointers into duplicated specialist protocols inside this
router.