← All craftbooks

QA

Review and QAevalv1.0.0released 2026-05-16workflow: qa

Live UI QA pass with a real browser. Navigates the target, interacts with the golden-path flow, captures findings, fixes atomically, re-tests.

Steps

Entry step: smoke. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Smokereviewerentry

    Navigate to the target URL and verify the page loads + the golden-path element is visible.

    Show working prompt
    First task: smoke the target.
    
    1. Resolve the URL from the user's chat message (or `ask_user_question` if missing).
    2. Run the `qa-trace` script with mode='smoke' and the URL. It returns a YAML accessibility snapshot of the page after navigation.
    3. Look at the snapshot. Does the page look loaded? Is the primary CTA visible? Is there an obvious error banner?
    
    If the smoke fails (404, 500, blank page), branch to halt. Otherwise advance.
  2. Exercise the flowreviewer

    Walk the golden path. Click the primary CTA, fill the form, submit, watch the result.

    Show working prompt
    Run the golden path. Use `run_playwright_script` to:
    
    1. Click the primary CTA (use the ref from the previous snapshot).
    2. Fill any visible form fields with plausible test data.
    3. Submit.
    4. Capture a follow-up snapshot.
    5. Verify the success state is visible (URL change, success message, expected next-screen element).
    
    Document what you saw in task notes. If the flow completes cleanly, advance to edge-cases. If anything breaks, branch to triage.
  3. Edgesreviewer

    Try a small set of edge cases: empty input, oversized input, invalid input, double-click, browser back.

    Show working prompt
    Run 3-5 edge cases against the same flow. Pick the ones most likely to actually catch a real bug:
    
    - Submit with empty required field — does the form give a useful error?
    - Submit with an absurd value (10K-char string, negative number, malformed email) — does it crash or sanitize?
    - Click submit twice rapidly — does it double-submit?
    - Browser back after submit — does the app go to a sane state?
    
    Document findings. If any case breaks badly, branch to triage. Otherwise advance to summary.
  4. Summaryreviewer

    Clean pass. Stamp a brief 'QA passed' note and DONE.

    Show working prompt
    Write a one-paragraph DONE summary: URL, flow exercised, edge cases tried, all green. Note any 'consider for follow-up' items (UX papercuts, missing instrumentation) — non-blocking.
  5. Triagereviewer

    Surface what broke. Stamp a clear finding and STOP — fix happens in a separate task.

    Show working prompt
    QA found something. Write a finding to task notes:
    
    - **What broke** (one sentence, observable)
    - **Where** (URL + element + step that triggered it)
    - **Severity** (blocker / major / minor)
    - **Suggested next action** (file an issue / hotfix / acceptable risk)
    
    This craftbook does NOT fix bugs — that's `/investigate` + edit. Report DONE_WITH_CONCERNS and let the user route the fix.
  6. Haltedreviewer

    Smoke failed before any real testing happened. Surface it.

    Show working prompt
    The target page didn't load or had an obvious blocker (404, 500, blank). Surface the specific failure in task notes and report DONE_WITH_CONCERNS. Don't try to test on top of a broken smoke.

Triggers

Phrases that suggest this craftbook to a crew.

Source

View this craftbook on GitHub · MIT license