/hands-on-test
Performs manual hands-on testing of a web application using playwright-cli. Spawns the dev server if needed, navigates to pages, performs browser actions, captures screenshots, checks outcomes, and produces a structured test report. Use when the user wants to visually verify a
Claude Code
$ npx -y skills add ktnyt/cclsp --skill hands-on-test --agent claude-code
Codex
$ npx skills add ktnyt/cclsp --skill hands-on-test -a codex -y
Cursor
$ npx skills add ktnyt/cclsp --skill hands-on-test -a cursor -y
Gemini CLI
$ npx skills add ktnyt/cclsp --skill hands-on-test -a gemini-cli -y
GitHub Copilot
$ npx skills add ktnyt/cclsp --skill hands-on-test -a github-copilot -y
OpenCode
$ npx skills add ktnyt/cclsp --skill hands-on-test -a opencode -y
Windsurf
$ npx skills add ktnyt/cclsp --skill hands-on-test -a windsurf -y
SKILL.md
hands-on-test.SKILL.mdname: hands-on-test
description: Performs manual hands-on testing of a web application using playwright-cli. Spawns the dev server if needed, navigates to pages, performs browser actions, captures screenshots, checks outcomes, and produces a structured test report. Use when the user wants to visually verify a web feature, perform exploratory testing, or validate UI behavior.
allowed-tools: Bash(playwright-cli:*), Bash(docker compose:*), Bash(lsof:*), Bash(curl:*), Bash(mkdir:*), Bash(date:*), Read, Write
Hands-On Testing with playwright-cli
Perform manual browser-based testing of a web application and produce a structured test report with screenshots and console output.
Workflow
Phase 1: Environment Setup
1.1 Create the test output directory
Generate a timestamp-based output directory for this test run:
TEST_OUTPUT_DIR="$CLAUDE_PROJECT_DIR/test-output/$(date +%Y%m%d%H%M)"
mkdir -p "$TEST_OUTPUT_DIR"
All screenshots and the report for this run will be saved under this directory.
1.2 Check if the dev server is running
# Check if something is listening on the expected port
lsof -i :3000 -sTCP:LISTEN
# or
curl -s -o /dev/null -w "%{http_code}" http://localhost:30001.3 Start the dev server if not running
Detect the project's dev server command from project files (`compose.yml`, `package.json`, `Makefile`, etc.) and start it in the background.
# Example: Docker Compose project
docker compose up -d
# Example: Node.js project
# npm run dev &
Wait for the server to become ready:
# Poll until the server responds
for i in $(seq 1 30); do
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 | grep -q "200" && break
sleep 1
donePhase 2: Browser Session
2.1 Open the browser and navigate
playwright-cli open http://localhost:3000
Or navigate to a specific page to test:
playwright-cli open http://localhost:3000/path/to/test
2.2 Take a snapshot to understand the page structure
playwright-cli snapshot
Use the snapshot output to identify element refs (e.g., `e1`, `e5`, `e12`) for subsequent interactions.
2.3 Perform test actions
Interact with the page based on the test scenario. Common actions:
# Click elements
playwright-cli click e3
# Fill form fields
playwright-cli fill e5 "test input"
# Type text (simulates keystrokes)
playwright-cli type "search query"
# Press keys
playwright-cli press Enter
# Select dropdown options
playwright-cli select e9 "option-value"
# Check/uncheck checkboxes
playwright-cli check e12
playwright-cli uncheck e12
# Hover
playwright-cli hover e4
# Navigate
playwright-cli goto http://localhost:3000/other-page
After each significant action, take a snapshot to verify the page state:
playwright-cli snapshot
2.4 Capture screenshots
Save screenshots to `$TEST_OUTPUT_DIR/` with descriptive filenames:
# Full page screenshot
playwright-cli screenshot --filename=$TEST_OUTPUT_DIR/<test-name>-<step>.png
# Screenshot of a specific element
playwright-cli screenshot e5 --filename=$TEST_OUTPUT_DIR/<test-name>-<element>.png
**Naming convention**: `<test-name>-<step-number>-<description>.png`
Examples:
- `login-01-initial.png`
- `login-02-filled-form.png`
- `login-03-after-submit.png`
- `dashboard-01-loaded.png`
2.5 Collect console messages
playwright-cli console
Check for errors, warnings, or relevant log output.
2.6 Collect network activity (if relevant)
playwright-cli network
Phase 3: Outcome Verification
After performing actions and capturing state:
1. **Read the screenshot** using the Read tool to visually inspect the result 2. **Review the snapshot** to verify DOM state matches expectations 3. **Check console output** for errors or unexpected warnings 4. **Compare** the actual outcome against the intended behavior described in the test scenario
Phase 4: Cleanup
playwright-cli close
Phase 5: Report Generation
Write a structured test report to `$TEST_OUTPUT_DIR/REPORT.md`:
# Hands-On Test Report
**Date**: YYYY-MM-DD HH:MM
**Tester**: <agent-name>
**Target**: <URL tested>
## Test Scenario
<Brief description of what was being tested>
## Steps Performed
| # | Action | Target | Details |
|---|--------|--------|---------|
| 1 | Navigate | http://localhost:3000/page | Initial page load |
| 2 | Fill | e5 (Email field) | Entered "user@example.com" |
| 3 | Click | e8 (Submit button) | Submitted form |
## Screenshots
| Step | Screenshot | Description |
|------|-----------|-------------|
| 1 |  | Page after initial load |
| 2 |  | Form with data entered |
| 3 |  | Result after submission |
## Console Output
<relevant console messages, warnings, or errors>
## Result
**Status**: PASS / FAIL
<Explanation of whether the outcome matched expectations.
If FAIL, describe the discrepancy between expected and actual behavior.>
Example: Full Test Session
# Phase 1: Setup
TEST_OUTPUT_DIR="$CLAUDE_PROJECT_DIR/test-output/$(date +%Y%m%d%H%M)"
mkdir -p "$TEST_OUTPUT_DIR"
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000
# If not running:
docker compose up -d
# Wait for ready
for i in $(seq 1 30); do
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 | grep -q "200" && break
sleep 1
done
# Phase 2: Test
playwright-cli open http://localhost:3000/login
playwright-cli snapshot
playwright-cli screenshot --filename=$TEST_OUTPUT_DIR/login-01-initial.png
playwright-cli fill e5 "user@example.com"
playwright-cli fill e8 "password123"
playwright-cli screenshot --filename=$TEST_OUTPUT_DIR/login-02-filled.png
playwright-cli click e10
playwright-cli snapshot
playwright-cli screenshot --filename=$TEST_OUTPUT_DIR/login-03-result.png
playwright-cli console
# PRead more
name: hands-on-test description: Performs manual hands-on testing of a web application using playwright-cli. Spawns the dev server if needed, navigates to pages, performs browser actions, captures screenshots, checks outcomes, and produces a structured test report. Use when the user wants to visually verify a web feature, perform exploratory testing, or validate UI behavior. allowed-tools: Bash(playwright-cli:*), Bash(docker compose:*), Bash(lsof:*), Bash(curl:*), Bash(mkdir:*), Bash(date:*), Read, Write
Hands-On Testing with playwright-cli
Perform manual browser-based testing of a web application and produce a structured test report with screenshots and console output.
Workflow
Phase 1: Environment Setup
1.1 Create the test output directory
Generate a timestamp-based output directory for this test run:
TEST_OUTPUT_DIR="$CLAUDE_PROJECT_DIR/test-output/$(date +%Y%m%d%H%M)" mkdir -p "$TEST_OUTPUT_DIR"
All screenshots and the report for this run will be saved under this directory.
1.2 Check if the dev server is running
# Check if something is listening on the expected port
lsof -i :3000 -sTCP:LISTEN
# or
curl -s -o /dev/null -w "%{http_code}" http://localhost:30001.3 Start the dev server if not running
Detect the project's dev server command from project files (`compose.yml`, `package.json`, `Makefile`, etc.) and start it in the background.
# Example: Docker Compose project docker compose up -d # Example: Node.js project # npm run dev &
Wait for the server to become ready:
# Poll until the server responds
for i in $(seq 1 30); do
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 | grep -q "200" && break
sleep 1
donePhase 2: Browser Session
2.1 Open the browser and navigate
playwright-cli open http://localhost:3000
Or navigate to a specific page to test:
playwright-cli open http://localhost:3000/path/to/test
2.2 Take a snapshot to understand the page structure
playwright-cli snapshot
Use the snapshot output to identify element refs (e.g., `e1`, `e5`, `e12`) for subsequent interactions.
2.3 Perform test actions
Interact with the page based on the test scenario. Common actions:
# Click elements playwright-cli click e3 # Fill form fields playwright-cli fill e5 "test input" # Type text (simulates keystrokes) playwright-cli type "search query" # Press keys playwright-cli press Enter # Select dropdown options playwright-cli select e9 "option-value" # Check/uncheck checkboxes playwright-cli check e12 playwright-cli uncheck e12 # Hover playwright-cli hover e4 # Navigate playwright-cli goto http://localhost:3000/other-page
After each significant action, take a snapshot to verify the page state:
playwright-cli snapshot
2.4 Capture screenshots
Save screenshots to `$TEST_OUTPUT_DIR/` with descriptive filenames:
# Full page screenshot playwright-cli screenshot --filename=$TEST_OUTPUT_DIR/<test-name>-<step>.png # Screenshot of a specific element playwright-cli screenshot e5 --filename=$TEST_OUTPUT_DIR/<test-name>-<element>.png
**Naming convention**: `<test-name>-<step-number>-<description>.png`
Examples:
- `login-01-initial.png`
- `login-02-filled-form.png`
- `login-03-after-submit.png`
- `dashboard-01-loaded.png`
2.5 Collect console messages
playwright-cli console
Check for errors, warnings, or relevant log output.
2.6 Collect network activity (if relevant)
playwright-cli network
Phase 3: Outcome Verification
After performing actions and capturing state:
1. **Read the screenshot** using the Read tool to visually inspect the result 2. **Review the snapshot** to verify DOM state matches expectations 3. **Check console output** for errors or unexpected warnings 4. **Compare** the actual outcome against the intended behavior described in the test scenario
Phase 4: Cleanup
playwright-cli close
Phase 5: Report Generation
Write a structured test report to `$TEST_OUTPUT_DIR/REPORT.md`:
# Hands-On Test Report **Date**: YYYY-MM-DD HH:MM **Tester**: <agent-name> **Target**: <URL tested> ## Test Scenario <Brief description of what was being tested> ## Steps Performed | # | Action | Target | Details | |---|--------|--------|---------| | 1 | Navigate | http://localhost:3000/page | Initial page load | | 2 | Fill | e5 (Email field) | Entered "user@example.com" | | 3 | Click | e8 (Submit button) | Submitted form | ## Screenshots | Step | Screenshot | Description | |------|-----------|-------------| | 1 |  | Page after initial load | | 2 |  | Form with data entered | | 3 |  | Result after submission | ## Console Output
<relevant console messages, warnings, or errors>
## Result **Status**: PASS / FAIL <Explanation of whether the outcome matched expectations. If FAIL, describe the discrepancy between expected and actual behavior.>
Example: Full Test Session
# Phase 1: Setup
TEST_OUTPUT_DIR="$CLAUDE_PROJECT_DIR/test-output/$(date +%Y%m%d%H%M)"
mkdir -p "$TEST_OUTPUT_DIR"
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000
# If not running:
docker compose up -d
# Wait for ready
for i in $(seq 1 30); do
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 | grep -q "200" && break
sleep 1
done
# Phase 2: Test
playwright-cli open http://localhost:3000/login
playwright-cli snapshot
playwright-cli screenshot --filename=$TEST_OUTPUT_DIR/login-01-initial.png
playwright-cli fill e5 "user@example.com"
playwright-cli fill e8 "password123"
playwright-cli screenshot --filename=$TEST_OUTPUT_DIR/login-02-filled.png
playwright-cli click e10
playwright-cli snapshot
playwright-cli screenshot --filename=$TEST_OUTPUT_DIR/login-03-result.png
playwright-cli console
# Pcclsp is a Model Context Protocol (MCP) server that seamlessly integrates LLM-based coding agents with Language Server Protocol (LSP) servers.
Other skills on cclsp.
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about hands-on-test.
- Which coding agents can use hands-on-test?
- hands-on-test installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

