From qa-persona
Use when driving Layer 2 (browser walkthrough) for one or more catalog scenarios — captures screenshots into evidence/, fills in the Run
How this skill is triggered — by the user, by Claude, or both
Slash command
/qa-persona:qa-persona-walkthroughThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Drive a Layer 2 (browser) walkthrough for the named scenarios. Captures screenshots into `evidence/qa-persona/` and fills in the Run #N narrative skeleton that `qa-persona-iterate` staged.
Drive a Layer 2 (browser) walkthrough for the named scenarios. Captures screenshots into evidence/qa-persona/ and fills in the Run #N narrative skeleton that qa-persona-iterate staged.
Pre-condition: Layer 1 (run-all.sh) for the same scenarios is green. If Layer 1 is red, refuse — fix backend first; mixing layers conflates UX and backend bugs.
$ARGUMENTS — scenario IDs space-separated, or all. Optional trailing --parallel flag.
Examples:
A1 — single canonical happy pathA1 D1 G1 — Run #1 first-batch compositionall — re-walk every catalog scenarioE1 E3 --parallel — concurrent multi-actor scenarios with one sub-agent per persona--parallelDefault is sequential — one Claude drives every persona in turn. That's correct for A/B/C/F/G scenarios where the test is "did the lifecycle close cleanly," not "did concurrent actors race."
Use --parallel when the scenario itself is about concurrency — i.e. when sequential walkthrough literally cannot exercise the codepath under test:
For everything else, sub-agent overhead exceeds the benefit. Default to sequential.
docs/qa-persona/scenarios.md exists.scripts/qa/<flow>-e2e/run-all.sh '<filter matching $ARGUMENTS>'. If any FAIL, stop and tell the user. Do NOT proceed to browser.gstack slash command available (/browse) → preferred for goto+screenshot checks.npx playwright resolves → use it.puppeteer in node_modules → use it.about:blank until restart) — most often on Windows. If /browse blanks mid-flow, switch to a per-call driver rather than restarting in a loop. Switch personas with localStorage.clear() + re-login.README.md, package.json scripts, .env). If unclear, ask.For each scenario in $ARGUMENTS:
Read scripts/qa/<flow>-e2e/scenarios/<ID>-*.sh to extract the persona sequence and the assertion shape (what state should exist at the end). The browser walkthrough mirrors this sequence in the UI.
For each persona action in the scenario:
evidence/qa-persona/run-N-<ID>-step-M-before.png.evidence/qa-persona/run-N-<ID>-step-M-after.png.At the scenario's end, the UI state should match what verify_<entity> would print. If it doesn't, that's a Layer-2-only bug (the data is right, the UI lies about it).
Open the walkthrough doc (latest walkthrough-RUN-*.md). Find the ## Run #N skeleton staged by qa-persona-iterate (or create one if missing). For each scenario walked, append:
### <ID> — <persona> does <action> (UI: /<route>)
`<persona>` logged in. <What was visible — sidebar, page state, copy, response timing.>
✅ **What worked:** <concrete observation with quoted UI copy or numbers>
⚠️ **Friction:** <list>
🔴 **Gap (design vs reality):** <if any>
🐛 **Bug:** <symptom + repro + severity + fix sketch — short>
Copy templates/swimlane-report.html to evidence/qa-persona/swimlane-RUN-N.html (same dir as the screenshots — it references them by relative path). Replace only the DATA = {…} block: one entry in personas[] per persona, in handoff order; each step records the planned path (action, expected) AND the actual result (actual, status, shot), plus a handoff to the next persona where the output feeds them. End each lane with a conclusion + verdict. Untested planned steps go in with status:"info" and no actual. This is the at-a-glance review surface — the markdown journal is the analysis, the swimlane is the visual.
For every 🐛 logged: add a new row to docs/qa-persona/bugs.md with a stable ID, severity, where, fix sketch, status 🔴. The new bug IDs go into the Run #N "New bugs surfaced" line.
Fill in the BR coverage table delta and write a one-paragraph verdict: did the value loop close end-to-end in the browser, yes or no, and what's blocking if no.
When --parallel is set:
For each $ARGUMENTS scenario, read scripts/qa/<flow>-e2e/scenarios/<ID>-*.sh and extract every persona email referenced. Group by email — one sub-agent per distinct persona.
Use the Agent tool with subagent_type: general-purpose. All sub-agents launched in one message run concurrently — that's the only way to test real concurrency. Each prompt MUST include the persona-isolation contract verbatim:
You are persona
<email>. You have ONLY this persona's credentials, view, and history. You do NOT know any other persona's password, session token, internal state, or recent actions. If a step requires information another persona holds, you must obtain it via the system's normal channels (notifications, broadcast, polling) — never out-of-band. If you cannot complete a step using only your persona's view, log it as 🔴 "missing UX affordance" and proceed.
Each sub-agent prompt also includes:
scripts/qa/<flow>-e2e/scenarios/<ID>-*.sh).evidence/qa-persona/run-N-<ID>/<persona-slug>/ (one per persona — prevents filename collisions when multiple personas screenshot the same UI route at the same wall-clock).{step, ts, what_worked, friction, gaps, bugs} for each action taken, plus screenshot paths.After all sub-agents return, the coordinator (you, in this conversation):
docs/qa-persona/bugs.md and the narrative into the walkthrough doc as in sequential mode.verify_<entity> returns; don't rely on screenshot mtime.## Run # section. Append-only.npx claudepluginhub andreykuzin/qa-persona --plugin qa-personaProvides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.