Aie web qa

Skill mrhinkle/aienterprise-skills/plugins/aie-web/skills/aie-web-qa

Open source Agent Skills for Claude Code and Cowork — writing, web, social, and chief-of-staff bundles (12 skills).

Install

npx -y skills add mrhinkle/aienterprise-skills --skill aie-web-qa

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Runs a unified pre-launch or post-update quality-assurance pass on a website — the holistic "does this actually work?" gate. Walks pages, forms, navigation, third-party integrations, cross-browser and mobile behavior, JavaScript console health, accessibility basics, HTTPS/security, and a performance smoke test. Produces a QA report with issues rated by severity, reproduction steps, and a launch recommendation; supports regression testing after fixes. Stack-agnostic. Trigger on "QA my site," "test my site," "does everything work," "smoke test," "test before launch," "regression test," "check all pages," "test my forms," "check mobile," "cross-browser test," "broken links," or "is my site ready to launch."

SKILL.md

5.7 KB, as published. Nobody here has run it

Web QA Tester

The final quality gate before a site ships or an update goes live. Individual audits answer narrow questions; QA answers the real one: does this thing actually work? It catches the failures that live in the gaps — forms that pass validation but don't send, pages that load but feel broken, third-party scripts that fail silently, mobile layouts that look fine but aren't tappable.

When to use this skill

Pre-launch — a new site or major redesign about to go live.
Post-update — changes to an existing site that need a regression check before deploy.
Any "test it before it breaks in front of users" moment.

Inputs

The site URL (staging is preferred over production).
For post-update runs: which pages/features changed.
Access to any forms and third-party integrations you need to verify (email delivery, analytics, payments, embeds).

Test categories

Run the relevant categories. Full item-by-item checklists live in reference/qa-checklist.md; read it before executing.

Page rendering — every page returns 200 (or an intended 3xx); no blank pages, broken images, or missing content; layout holds at 320/768/1024/1440px.
Cross-browser — Chrome/Edge, Safari (macOS + iOS use WebKit), Firefox. Check forms, JS, layout, media, animations.
Mobile & responsive — correct viewport meta, no horizontal scroll, tap targets ~48x48px+, mobile-friendly forms; test 320/375/768/1024/1440px.
Forms — every field fillable, validation correct, clear error messages, no double-submit, real confirmation (message/redirect/email actually arrives), no sensitive data leaking to console or URL.
JavaScript console health — zero red errors, no unhandled promise rejections, no failed requests that break features, third-party scripts load clean.
Navigation flow — every link resolves, breadcrumbs accurate, back button works, a professional 404 exists, no dead ends, mobile menu works.
Third-party integrations — analytics, email service, payments, embeds, tracking pixels, external CDNs all load and function. Verify with a real test, not [email protected].
Accessibility basics — keyboard navigation and visible focus, alt text, labeled controls, WCAG AA color contrast, ARIA roles on complex widgets. Reference: https://www.w3.org/WAI/WCAG22/quickref/
Visual regression — consistent spacing, no overlap, correctly sized images, fonts load without a flash, aligned icons, visible hover/interactive states.
SSL / security — HTTPS everywhere, valid certificate, no mixed content, HSTS present.
Performance smoke test — pages usable in under ~3s on 4G; LCP < 2.5s; minimal CLS. For a full pass, hand off to aie-web-performance.

Execution protocol

Pre-launch (new site): open the site in Chrome, Safari, Firefox, and Edge with DevTools Console open; walk every unique page; fill and submit every form; exercise every interactive element; do a dedicated mobile pass at 375px; verify each integration with a real test.

Post-update (existing site): identify changed pages and anything the change could ripple into (shared CSS/JS); regression-test the changed features using the exact reproduction steps; smoke-test 3-5 unchanged pages to confirm nothing else broke; deploy only when blockers and criticals are clear.

Severity levels

Severity	Meaning	Action
Blocker	Site unusable / core function broken	Do not launch. Fix now.
Critical	Users can't complete a primary task	Fix before launch.
Major	Degraded but partly usable	Fix before launch.
Minor	Non-critical or edge case	Fix after launch if time allows.
Cosmetic	Visual only, no functional impact	Backlog.

Output format

QA TEST REPORT
Site: {url}    Date: {date}    Environment: {staging/production}

OVERALL: PASS / PASS WITH KNOWN ISSUES / FAIL

ISSUES FOUND
  #. {summary}
     Severity: {level}
     Location: {page/element}
     Steps to reproduce: {steps}
     Expected: {expected}
     Actual: {actual}
     Fix: {concrete fix}

TESTS PASSED
  ✓ {what passed, with counts, e.g. "11/11 pages render clean"}

REGRESSION (post-update only)
  Previously failed: {issue} -> Result: FIXED / STILL FAILING

RECOMMENDATION
  {launch / hold}; blockers remaining: {n}; est. fix time: {x}

Regression testing

After fixes, re-run only the failed tests using the exact reproduction steps. Confirm the issue is gone and that the fix introduced no new console errors. Mark FIXED. Don't re-test everything — just what was broken plus a quick console spot-check.

Notes

QA is a gift, not a punishment — finding problems before users do is far cheaper than after.
Prefer testing on staging. If only production is available, avoid submitting real transactions or polluting analytics/CRM with test data.
Where automated fetching can't fully execute JavaScript or reach authenticated pages, say so and recommend a manual or headless-browser pass for those flows.