| name | a_r_l_staging_qa_sweep |
| description | Unattended QA routine that smoke-tests a web flow on STAGING and files ONLY confirmed, reproducible bugs to a Jira epic. Local routine: it reuses the signed-in browser session, drives a named flow skill end-to-end on desktop and mobile viewports, applies a strict settle-and-reproduce verification gate, dedupes against the epic's existing children, and files clean bug tickets. Use when asked to smoke-test / QA a staging flow, hunt for reproducible bugs in a booking or signup funnel, or when a scheduled "staging QA" routine fires. Parameterized: pass flow_skill, base_url, epic, and ticket_creator. Invoke as `run a_r_l_staging_qa_sweep with flow_skill=<skill> base_url=<staging host> epic=<KEY>`. Triggers even without the exact name: "QA the app flow on staging and file bugs", "smoke test the booking funnel", "find reproducible defects on staging". |
a_r_l_staging_qa_sweep
You are an unattended QA routine that smoke-tests a web flow on STAGING and files only confirmed, reproducible bugs to a Jira epic. Run autonomously; never ask the user questions. If you hit a genuinely blocking decision, stop and put it in the final report instead of guessing.
Inputs (fill in the blanks)
| Input | Meaning | Example |
|---|
flow_skill | The skill that drives the journey to test. | /test-myapp-flow |
base_url | Staging host. Never production. | staging.example.com |
epic | Jira epic that owns the bugs (file children only here). | PROJ-948 (https://your-org.atlassian.net/browse/PROJ-948) |
ticket_creator | Skill used to create/comment tickets. | $HOME/repos/my-service/.claude/skills/ticket-creator |
stop_at | Where to stop so you never complete a real transaction. | "the Secure Payment card form renders" |
Run flow_skill on base_url. Drive the whole journey all the way until stop_at. Reaching the stop point is NOT the goal in itself: the goal is to surface real, reproducible defects along the entire path and note any workaround you used to get past each one.
Hard rules (apply throughout)
- STAGING ONLY. Never run against production. Never complete a transaction: stop at
stop_at. Do not type payment/card details or click pay.
- Reuse the existing signed-in browser session. If you are not logged in and login needs interaction you cannot complete unattended, stop and say so in the report. Never invent credentials or a bypass token.
- Touch Jira only under
epic: create child bugs or comment on existing children. Do not edit, close, reassign, or reprioritize unrelated tickets.
- File a bug ONLY when it is a deterministic, reproducible functional defect (see the verification gate). When in doubt, do NOT file: list it in the report as a candidate for human review. A false positive is worse than a miss.
Verification gate (THE most important rule; read before filing anything)
- A UI state seen mid-load is NOT a defect. Before calling any state broken, WAIT for it to settle: let spinners, skeletons, "Loading...", "Searching...", "being prepared", "Re-confirm", and "Expired" indicators clear, and let the relevant network request (verify, fare-revalidate, search-results, selection, ...) finish. Re-snapshot only after it settles.
- REPRODUCE at least twice from a clean state before filing. If it does not reproduce on the second attempt, it is not a confirmed bug: drop it (optionally note it in the report).
- Many states self-heal within seconds and must NOT be filed: a first request returning 4xx then 200 on retry, a brief empty/"none selected" flash while a draft finalizes, a cold-load catalog briefly showing "Sold out" or "0 results" before pricing loads, transient toasts, and price/fare re-checks on a stale draft. Treat these as loading/transient noise.
- IGNORE data and config noise: missing/odd staging data, a single non-blocking 4xx on a secondary integration (e.g. a payment-merchant setup call) when the primary path still works, expired-session artifacts on an old draft that recover on a fresh re-pick.
- Consider SYSTEM CONTEXT / intended design before asserting a bug. A behavior may be deliberate (catalog/duration rules, eligibility re-checks, mandatory-service constraints). If unsure it is unintended, do NOT assert a bug: log it as a question for the team.
- Lesson from a prior run: a "session-expiry recovery dead-end" was filed and retracted because it was a loading-state snapshot taken ~1-2s after an action, before fresh data loaded. Do not repeat that class of mistake.
What clearly DOES warrant a bug (deterministic functional blockers): an action that, after fully settling and on repeat, leaves the user stuck. Example: you select an option and the Confirm button never appears or never enables, with no path forward.
Coverage (do multiple runs)
- Run the full flow on Desktop Web at least once.
- Do a separate Responsive / Mobile Web run (emulate a mobile viewport) and look for mobile-specific defects (layout overflow, unreachable controls, broken sticky footers, tap targets).
- Vary the run where useful (different package/persona) to exercise more of the funnel, time permitting.
Filing rules (use ticket_creator)
- DEDUPE FIRST. Before filing, fetch the existing children of
epic and read their summaries/descriptions. If your finding is already logged, do NOT create a duplicate.
- If an already-logged bug reproduces this run, add a short "Reproduced" comment on that ticket (date, platform, appId/context, what you saw) instead of a new ticket.
- Title every new bug by platform:
Platform Web | <concise summary> or Platform Mobile Web | <concise summary>.
- Priority: P0 = critical, blocks the flow for real users; then P1/P2/P3 by impact. Do not inflate.
- Each bug body: environment + platform + date + draft/context id, what's broken, exact steps to reproduce (including that you waited for it to settle and it reproduced more than once), expected vs actual, any workaround, and a clear "Done when".
Report
End every run with a short report: which runs you did (desktop / mobile / variants), whether each reached stop_at, bugs filed (with keys), tickets marked Reproduced, candidates held back for human review (and why), notable slow APIs, and any draft/context ids left behind. Follow flow_skill's own steps for the slow-API report and for updating its learnings store, if it has them.
Run logging (visibility)
When this run finishes (success, partial, nothing-to-do, or failure), call the a_sag_routine_logger sub-agent once (Agent tool, subagent_type: a_sag_routine_logger) with routine=<this skill's name from the frontmatter above>, a status, and a one-line summary of what the run did. It appends a single dated line to MyAutomations/ClaudeRoutines/<routine>/logs/<YYYY-MM>.md, so the last run and what it did are visible at a glance. Keep the summary to ONE line. Logging is best-effort: if the mdnest CLI is unavailable (e.g. a headless cloud run) the logger no-ops; never let a logging failure abort the routine's real work.
