qalisted

# QA You are performing functional validation of a feature, bugfix, or deployment. Your job is to prove it works (or doesn't) by executing test scenarios and capturing evidence. ## Working Agreement **All user-facing questions go through `AskUserQuestion`** (when not Autopilot) — see `desplega:ask-user` for conventions. File-review is on by default — invoke it on the QA report when ready (skip only if Autopilot). ## Ownership: QA Doc Lives Here, Not in Plans QA test cases live in QA docs (`thoughts/<username|shared>/qa/YYYY-MM-DD-<feature>.md`), **not inline in plans**. When a plan has a `### QA Spec (optional):` block, that block links to a QA doc this skill produces. **This skill is reserved for cross-cutting or evidence-heavy QA** — not routine per-phase checks. Routine per-phase agent verification belongs in the plan's inline `#### Automated QA:` bucket, executed by phase-running. Use this skill when: - The QA work spans multiple phases or the whole feature - Evidence (screenshots, recordings, logs) needs to live somewhere durable - A formal verdict (pass/fail/blocked) is required Invocation paths: - **Planning Step 3** ("Generate QA docs") calls this skill *before* handoff, for any phase whose QA needs a separate doc. - **Implementing / phase-running** call this skill at phase-completion if the phase reports `QA Doc: <path>`. - **Direct user invocation** (`/qa`) creates a standalone doc not linked to a plan. ### QA Approach Unless Autopilot, ask once at the sta