| name | qa-verification |
| description | Verifies implemented behavior with evidence. Use after implementation to gather proof, reproduce user flows, and decide whether the session is report-only or fix-enabled. Browser-visible work uses interactive verification paths; backend and Tauri-runtime work use smoke checks, task commands, and structured findings. |
QA Verification
Post-implementation verification skill for gathering evidence before final sign-off.
When to Use
- A change is implemented and needs user-flow verification.
- You need screenshots, proof artifacts, smoke-check evidence, or a structured bug report.
- The user explicitly wants QA, dogfooding, browser proof, or report-only verification.
Modes
report-only default: inspect, test, and report findings without changing repo-tracked files.fix-enabled: verify first, then fix the confirmed issues that fall inside scope.
Load / Do Not Load
- Load this skill after implementation, not during entry or initial planning.
- Do not use it as a substitute for
test-driven-development or code review checkpoints.
Core Workflow
- Choose the Verification Path: Browser-visible or desktop-visible flows use an interactive verification path; backend, CLI, and Tauri-runtime changes use smoke tests, task commands, and structured findings.
- Collect Evidence First: Reproduce the flow, capture failures, and note what passed.
- Respect the Mode Boundary:
report-only stops at evidence and findings. fix-enabled may edit only after the evidence is recorded.
- Summarize the Verification Story: Record what was checked, what failed, what was fixed, and what residual risk remains.
Ask / Escalate
- Ask when the expected user flow is ambiguous or the environment needed for verification is unavailable.
- Escalate when verification exposes auth, data-loss, filesystem, shell, network, or public-contract risk.
References
- Detailed guidance:
references/guidance.md
