Live Browser QA Pass
Run a hands-on quality-assurance pass on a running web app or page by actually exercising it in a browser, then emit a defect report with reproduction steps and severity. First derives a test plan and acceptance criteria from the app's intended behavior (happy paths, edge cases, error states, responsive/console health), then drives the UI step-by-step clicking and typing through each flow while watching the console and network for errors, then writes a bug report where every defect has numbered repro steps, expected vs actual, and severity. Use this for QA, manual testing, smoke testing, exploratory testing, click-testing a build, or verifying a feature works in the real browser before shipping — it finds broken flows, console errors, and visual breakage that unit tests miss.
Steps
Entry step: plan. Each step names the specialist role it wants; the full working prompt is expandable.
- Plan the QA passreviewerentry
enumerate flows + acceptance criteria to exercise
Show working prompt
Step 1: Identify what the app/page is supposed to do and how to reach it (URL, dev server, or open the file). Step 2: Enumerate the user flows to exercise: each happy path (e.g. 'submit the form with valid data'), the key edge cases (empty input, very long input, invalid data), and the error states (network failure, 404). Step 3: List the cross-cutting checks: no console errors on load or interaction, no broken images/links, responsive at mobile and desktop widths, keyboard operability of primary controls. Step 4: Write an acceptance-criteria checklist of 6-10 concrete, checkable behaviors, e.g. 'submitting valid data shows a success state', 'submitting empty data shows an inline validation error, not a crash', 'no red console errors during any flow'. Step 5: Note test data to use and any setup needed. Write the flow list + checklist to `write_task_note` AND `notes/plan.md`. No testing yet.
- Exercise the appreviewer
drive each flow in a browser, capture defects
Show working prompt
Step 1: Open the app (use the browser/automation capability if available — navigate, click, type, screenshot; otherwise trace the rendered DOM and JS by reading the source and reason about each interaction). Step 2: Run each planned flow step-by-step, recording the exact actions taken. Step 3: After every action, check the result against the acceptance criterion AND watch the console/network for errors or failed requests. Step 4: For every defect, capture: the flow, numbered reproduction steps, the EXPECTED result, the ACTUAL result, the severity (critical = blocks the flow / major = wrong but workaroundable / minor = cosmetic), and a screenshot or console excerpt if available. Step 5: Also record what PASSED so the report shows coverage, not just failures. Good looks like: a defect a developer can reproduce on the first try from your steps. Stage findings to `write_task_note` as you go. Do not write the final report yet.
- Write the QA reportreviewer
emit a defect report with repro + severity
Show working prompt
Step 1: Open `qa-report.md` and write a top-line verdict: Pass / Pass-with-issues / Fail, plus the count of defects by severity. Step 2: Add a '## Defects' section; for each defect write `### [SEVERITY] short title` followed by numbered repro steps, an Expected line, an Actual line, and any console/screenshot evidence. Order by severity. Step 3: Add a '## Passed' section listing the flows that worked, so coverage is visible. Step 4: Add a '## Not tested' section for anything you could not reach and why. Every defect must have reproducible steps and an expected-vs-actual — no vague 'it seems broken'. On a loop-back, fix only the named gaps without dropping verified defects. `write_task_note` the report path and the defect counts by severity.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open `qa-report.md` and grade it against the plan checklist. Check EACH criterion and write PASS/FAIL with a one-line reason: (1) every planned flow is marked tested with a result; (2) each defect has numbered, reproducible steps; (3) each defect states Expected vs Actual; (4) each defect has a severity; (5) console/network health was actually checked, not assumed; (6) a Passed section shows coverage and a Not-tested section is honest; (7) the verdict matches the findings (no 'Pass' with an open critical). If any criterion fails, name the exact gap. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "report" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- qa this
- run a qa pass
- test this in the browser
- smoke test the app
- click through the app
- manual test the feature
Source
View this craftbook on GitHub · MIT license