$npx -y skills add github/awesome-copilot --skill scoutqa-testThis skill should be used when the user asks to "test this website", "run exploratory testing", "check for accessibility issues", "verify the login flow works", "find bugs on this page", or requests automated QA testing. Triggers on web application testing scenarios including smo
| 1 | # ScoutQA Testing Skill |
| 2 | |
| 3 | Perform AI-powered exploratory testing on web applications using the `scoutqa` CLI. |
| 4 | |
| 5 | **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. |
| 6 | |
| 7 | ## When to Use This Skill |
| 8 | |
| 9 | Use this skill in two scenarios: |
| 10 | |
| 11 | 1. **User requests testing** - When the user explicitly asks to test a website or verify functionality |
| 12 | 2. **Proactive verification** - After implementing web features, automatically run tests to verify the implementation works correctly |
| 13 | |
| 14 | **Example proactive usage:** |
| 15 | |
| 16 | - After implementing a login form → Test the authentication flow |
| 17 | - After adding form validation → Verify validation rules and error handling |
| 18 | - After building a checkout flow → Test the end-to-end purchase process |
| 19 | - After fixing a bug → Verify the fix works and didn't break other features |
| 20 | |
| 21 | **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. |
| 22 | |
| 23 | ## Running Tests |
| 24 | |
| 25 | ### Testing Workflow |
| 26 | |
| 27 | Copy this checklist and track your progress: |
| 28 | |
| 29 | Testing Progress: |
| 30 | |
| 31 | - [ ] Write specific test prompt with clear expectations |
| 32 | - [ ] Run scoutqa command in background |
| 33 | - [ ] Inform user of execution ID and browser URL |
| 34 | - [ ] Extract and analyze results |
| 35 | |
| 36 | **Step 1: Write specific test prompt** |
| 37 | |
| 38 | See "Writing Effective Prompts" section below for guidelines. |
| 39 | |
| 40 | **Step 2: Run scoutqa command** |
| 41 | |
| 42 | **IMPORTANT**: Use the Bash tool's timeout parameter (5000ms = 5 seconds) to capture execution details: |
| 43 | |
| 44 | When calling the Bash tool, set `timeout: 5000` as a parameter: |
| 45 | |
| 46 | - This is the Bash tool's built-in timeout parameter in Claude Code (NOT the Unix `timeout` command) |
| 47 | - After 5 seconds, the Bash tool returns control with a task ID and the process continues running in the background |
| 48 | - This is different from Unix `timeout` which kills the process - here the process keeps running |
| 49 | - The first 5 seconds capture the execution ID and browser URL from ScoutQA's output |
| 50 | - The test continues running remotely on ScoutQA's infrastructure with the background task |
| 51 | |
| 52 | ```bash |
| 53 | scoutqa --url "https://example.com" --prompt "Your test instructions" |
| 54 | ``` |
| 55 | |
| 56 | In the first few seconds, the command will output: |
| 57 | |
| 58 | - **Execution ID** (e.g., `019b831d-xxx`) |
| 59 | - **Browser URL** (e.g., `https://app.scoutqa.ai/t/019b831d-xxx`) |
| 60 | - Initial tool calls showing test progress |
| 61 | |
| 62 | 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. |
| 63 | |
| 64 | **Step 3: Inform user of execution ID and browser URL** |
| 65 | |
| 66 | After the Bash tool returns with the task ID (having captured the execution details in the first 5 seconds), inform the user of: |
| 67 | |
| 68 | - The ScoutQA execution ID and browser URL so they can monitor progress in their browser |
| 69 | - The background task ID if they want to check local command output later |
| 70 | |
| 71 | The test continues running in the background while you continue other work. |
| 72 | |
| 73 | **Step 4: Extract and analyze results** |
| 74 | |
| 75 | See "Presenting Results" section below for the complete format. |
| 76 | |
| 77 | ### Command Options |
| 78 | |
| 79 | - `--url` (required): Website URL to test (supports `localhost` / `127.0.0.1`) |
| 80 | - `--prompt` (required): Natural language testing instructions |
| 81 | - `--project-id` (optional): Associate with a project for tracking |
| 82 | - `-v, --verbose` (optional): Show all tool calls including internal ones |
| 83 | |
| 84 | ### Local Testing Support |
| 85 | |
| 86 | ScoutQA supports testing `localhost` and `127.0.0.1` URLs autonomously — no manual setup required. |
| 87 | |
| 88 | ```bash |
| 89 | # Seamlessly test a locally running app when you're developing your app |
| 90 | scoutqa --url "http://localhost:3000" --prompt "Test the registration form" |
| 91 | ``` |
| 92 | |
| 93 | ### When to Use Each Command |
| 94 | |
| 95 | **Starting a new test?** → Use `scoutqa --url --prompt` |
| 96 | **Verifying a known issue?** → Use `scoutqa issue-verify --issue-id <id>` |
| 97 | **Finding issue IDs from an execution?** → Use `scoutqa list-issues --execution-id <id>` |
| 98 | **Agent needs more context?** → Use `scoutqa send-message` (see "Following Up on Stuck Executions") |
| 99 | |
| 100 | ## Writing Effective Prompts |
| 101 | |
| 102 | Focus on **what to explore and verify**, not prescriptive steps. ScoutQA autonomously determines how to test. |
| 103 | |
| 104 | **Example: User registrat |