qa

Use when a user asks for QA planning, execution, review, release assessment, reporting, status, or test-tool recommendations and the correct PWDEV QA workflow must be selected safely.

SKILL.md

GitHub

Route PWDEV QA work

Select one installed qa-* workflow without expanding the user's authority. The router does not perform the selected workflow itself.

Read workflow, safety, and artifacts before routing.

Inputs

  • The user's explicit objective and requested operation.
  • Existing project context, requirements, criteria, approvals, target, and constraints.
  • The observed testing surface and risk when the explicit objective does not identify a workflow.
  • The QA skills actually present in the active plugin installation.

Procedure

  1. Identify the explicit intent first. Do not reinterpret review, status, or another named workflow from the tools that happen to be available.
  2. If explicit intent is absent, use the observed surface to narrow the choice, then use risk to choose the smallest workflow that answers the objective. Never infer authorization from risk.
  3. Select the candidate from this routing table:
Intent Candidate
initialize qa-init
strategy qa-strategy
execute tests qa-test
explore qa-explore
regression qa-regression
bug qa-bug
review qa-review
release qa-release
report qa-report
status qa-status
tooling qa-tooling
  1. Validate the selected route before returning it: the plugin-relative path skills/<candidate>/SKILL.md must exist and be a regular file. A missing, non-regular, or unreadable target is an error; never claim that an unavailable skill ran.
  2. State why the selected candidate applies. Identify close alternatives as not applicable and explain why. If no installed candidate fits, stop with an explicit routing error.
  3. Preserve external requirements, criteria, states, and approvals. The selected workflow may consume them but cannot silently replace their authority.
  4. Hand off to exactly one selected workflow and apply its authorization and stop conditions.

Output

Return this compact routing record before entering the selected skill:

ROUTE: <installed qa-* skill>
WHY: <explicit intent, or observed surface and risk>
NOT_APPLICABLE: <nearby candidates and reasons, or none>
LIMITATIONS: <missing context or tools, or none>
NEXT: <selected workflow entry>

If criteria required by the selected workflow are absent, do not invent them. Record the limitation and let the common workflow contract produce BLOCKED.

Failure modes

  • No explicit intent and insufficient surface or risk context: ask one focused question.
  • Selected skill path is absent, unreadable, a directory, or a symlink: return a routing error.
  • Required criteria are absent: preserve the absence; the QA result is BLOCKED, never PASS.
  • A requested operation exceeds authorization: stop before execution and identify the exact authorization needed.
  • A tool is missing or unverified: report the limitation; never fabricate an execution.

Safety

  • Routing never authorizes load, penetration testing, production access, or external effects.
  • qa-review and qa-status remain read-only even if the project has writable tools.
  • Never install tools, change personal configuration, publish, push, merge, or correct product code automatically.
  • Follow the evidence boundary and sanitization requirements before any artifact is accepted.

Related skills

The workflow candidates are the installed qa-* skills in the table above. qa-tooling is the tool recommendation entry. Specialist guidance uses installed qa-specialist-* skills only after a workflow requests the relevant surface; absence is a limitation, not an invented route.