qa-agent

Verifies landing page request flows, CRM integration, and mobile behavior before release.

Updated Aug 10, 2026
One-click install
npx skills add https://github.com/prostoali2207-gif/auto-parts-landing --skill qa-agent-prostoali2207-gif
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: qa-agent
Source: https://github.com/prostoali2207-gif/auto-parts-landing/tree/main/.agents/skills/qa-agent
Command: npx skills add https://github.com/prostoali2207-gif/auto-parts-landing --skill qa-agent-prostoali2207-gif

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents silent regressions in the Das Motors UAE auto-parts landing page by acting as an independent release gate that validates the real visitor request journey before deployment. ## Core Features & Use Cases - Contract-Based Verification: Checks implementation against Conversion, UX, Visual, and CRM integration contracts rather than trusting developer assumptions. - End-to-End Request Testing: Covers VIN and make/model/year vehicle paths, part identification alternatives, validation errors, failure recovery, photo uploads, and downstream CRM record verification. - Mobile and Accessibility Acceptance: Tests the request flow at mobile widths, keyboard operability, error identification, and Core Web Vitals thresholds. - Use Case: After a frontend change to the request form, run this Skill to execute the critical happy paths, verify one correct CRM record is created, and receive a PASS, FAIL, or BLOCKED release verdict with evidence. ## Quick Start Run the QA agent against the latest deployment of the landing page and give me a release verdict with evidence for the request flow and CRM integration.

Frequently Asked Questions about qa-agent

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test a landing page request form before release?

Build a contract matrix of what must remain true, then execute critical happy paths such as VIN plus part info plus contact through to a confirmed CRM record. Cover validation errors, failure recovery, and mobile completion, and record evidence for each scenario before issuing a verdict.

How to verify form submissions reach a CRM correctly?

Submit an identifiable test request through the live frontend, then inspect the downstream CRM for exactly one record with correct vehicle, part, contact, and photo field mapping. If CRM access is unavailable, mark the integration as BLOCKED or UNVERIFIED rather than passing it.

What should mobile QA cover for a lead generation page?

Test around 390px width for horizontal overflow, CTA reachability, tap target size, readable labels and errors, keyboard behavior, safe wrapping of long VIN or OEM strings, and photo selection. A desktop pass cannot compensate for a broken mobile request flow.

Does browser file type checking make uploads secure?

No. OWASP recommends extension allowlisting, server-side type and size controls, generated safe filenames, and not trusting the user-supplied Content-Type header. If server-side controls are not observable, record upload security as NOT VERIFIED.

When should a release be blocked instead of failed?

Use BLOCKED when a required environment, deployment, credentials, or safe CRM test capability prevents release-critical verification. Use FAIL when a reproducible release-critical defect exists. BLOCKED is never treated as a pass.