Scoutqa Test
Run AI-powered exploratory and accessibility QA on live web apps via the ScoutQA CLI after shipping features or when validating user flows.
Overview
ScoutQA Test is an agent skill most often used in Ship (also Build integrations) that runs ScoutQA CLI exploratory and accessibility testing on web applications.
Install
npx skills add https://github.com/github/awesome-copilot --skill scoutqa-testWhat is this skill?
- Triggers on explicit test requests and proactive runs after web feature work
- ScoutQA CLI for autonomous exploration, bug discovery, and flow validation
- Supports parallel ScoutQA runs for broader coverage in less wall-clock time
- Covers smoke tests, accessibility audits, e-commerce, and authentication scenarios
- parallel ScoutQA executions for coverage
Adoption & trust: 9.1k installs on skills.sh; 34.6k GitHub stars; 0/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped or just built a web flow but lack time for thorough exploratory, accessibility, and regression checks in the browser.
Who is it for?
Solo builders with a deployable URL who want fast AI-driven QA after feature work or on demand.
Skip if: Pure backend-only APIs with no browser surface, or teams that already mandate a full Playwright/Cypress suite and will not use an external QA CLI.
When should I use this skill?
User asks to test a website, run exploratory testing, check accessibility, verify login, find bugs—or after implementing web features to verify they work.
What do I get? / Deliverables
You get autonomous ScoutQA runs documenting broken flows, a11y issues, and regressions so fixes can land before users do.
- Exploratory test run results
- Accessibility and flow issue findings
- Regression notes after fixes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill’s value is verifying behavior, accessibility, and regressions—not authoring UI code. Testing is where smoke checks, login flows, e-commerce paths, and proactive post-implementation verification belong in the solo-builder journey.
Where it fits
After implementing form validation, run ScoutQA to confirm errors and happy paths in the browser.
Run parallel ScoutQA sessions on staging before tagging a release.
Smoke-test production-critical flows post-deploy.
Re-test a reported bug fix and adjacent checkout steps for regressions.
How it compares
Browser-focused exploratory QA via CLI skill—not in-repo Jest/Vitest unit tests or static linters alone.
Common Questions / FAQ
Who is scoutqa-test for?
Indie and solo developers on web apps who need smoke, flow, and accessibility checks without building a full manual QA ritual every sprint.
When should I use scoutqa-test?
Use it when asked to test a website or verify login/checkout; after implementing forms or auth in Build; before launch in Ship; or when validating fixes so nothing else broke.
Is scoutqa-test safe to install?
Review the Security Audits panel on this Prism page and treat ScoutQA CLI runs as network/browser access against URLs you control—do not point it at third-party production without permission.
SKILL.md
READMESKILL.md - Scoutqa Test
# ScoutQA Testing Skill Perform AI-powered exploratory testing on web applications using the `scoutqa` CLI. **Think of ScoutQA as an intelligent testing partner** that can autonomously explore, discover issues, and verify features. Delegate testing to multiple parallel ScoutQA executions to maximize coverage while saving time. ## When to Use This Skill Use this skill in two scenarios: 1. **User requests testing** - When the user explicitly asks to test a website or verify functionality 2. **Proactive verification** - After implementing web features, automatically run tests to verify the implementation works correctly **Example proactive usage:** - After implementing a login form → Test the authentication flow - After adding form validation → Verify validation rules and error handling - After building a checkout flow → Test the end-to-end purchase process - After fixing a bug → Verify the fix works and didn't break other features **Best practice**: When you finish implementing a web feature, proactively start a ScoutQA test in the background to verify it works while you continue with other tasks. ## Running Tests ### Testing Workflow Copy this checklist and track your progress: Testing Progress: - [ ] Write specific test prompt with clear expectations - [ ] Run scoutqa command in background - [ ] Inform user of execution ID and browser URL - [ ] Extract and analyze results **Step 1: Write specific test prompt** See "Writing Effective Prompts" section below for guidelines. **Step 2: Run scoutqa command** **IMPORTANT**: Use the Bash tool's timeout parameter (5000ms = 5 seconds) to capture execution details: When calling the Bash tool, set `timeout: 5000` as a parameter: - This is the Bash tool's built-in timeout parameter in Claude Code (NOT the Unix `timeout` command) - After 5 seconds, the Bash tool returns control with a task ID and the process continues running in the background - This is different from Unix `timeout` which kills the process - here the process keeps running - The first 5 seconds capture the execution ID and browser URL from ScoutQA's output - The test continues running remotely on ScoutQA's infrastructure with the background task ```bash scoutqa --url "https://example.com" --prompt "Your test instructions" ``` In the first few seconds, the command will output: - **Execution ID** (e.g., `019b831d-xxx`) - **Browser URL** (e.g., `https://app.scoutqa.ai/t/019b831d-xxx`) - Initial tool calls showing test progress After the 5-second timeout, the Bash tool returns a task ID and the command continues running in the background. You can work on other tasks while the test runs. The timeout is only to capture the initial output (execution ID and browser URL) - the test keeps running both locally as a background task and remotely on ScoutQA's infrastructure. **Step 3: Inform user of execution ID and browser URL** After the Bash tool returns with the task ID (having captured the execution details in the first 5 seconds), inform the user of: - The ScoutQA execution ID and browser URL so they can monitor progress in their browser - The background task ID if they want to check local command output later The test continues running in the background while you continue other work. **Step 4: Extract and analyze results** See "Presenting Results" section below for the complete format. ### Command Options - `--url` (required): Website URL to test (supports `localhost` / `127.0.0.1`) - `--prom