Smoke test
Skill makigjuro/cloudstack-ai-plugins/plugins/react-developer/skills/smoke-test
Claude Code plugin marketplace — AI-powered full-stack cloud engineer for .NET 10 + React 19 + Azure/Terraform/Helm projects. 29 skills, 6 agents, 14 rules.
npx -y skills add makigjuro/cloudstack-ai-plugins --skill smoke-testAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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
Smoke test the running frontend and API by navigating key routes with Playwright, checking for console errors and broken pages. Use after starting the dev server or to verify the app works before creating a PR.
SKILL.md
7.6 KB, as published. Nobody here has run it
Smoke Test
Navigate key application routes using Playwright and verify they render without errors.
Arguments
--frontend-only— Only test frontend routes (skip API health checks)--api-only— Only test API health endpoints--interactive— Run interactive CRUD flows after route testing (creates test data)--screenshot— Take screenshots of each page (saved to /tmp/smoke-test/){url}— Test a specific URL instead of the default routes
Configuration
Read cloudstack.json from the project root at the start of execution. Extract:
FRONTEND_PATH=frontend.path(default:web)DEV_PORT=frontend.devPort(default:5173)UI_LIBRARY=frontend.uiLibrary(default:shadcn)STATE_SERVER=frontend.stateManagement.server(default:tanstack-query)STATE_CLIENT=frontend.stateManagement.client(default:zustand)MULTI_TENANT=backend.multiTenancy(default:false)
Also extract:
API_PORT=backend.devPort(default:5000)ORCHESTRATOR=localDev.orchestrator(default:none) — e.g.,aspire,docker-compose,noneORCHESTRATOR_PORT=localDev.orchestratorPort(default:none)
If cloudstack.json does not exist, auto-detect by checking package.json dependencies.
Auth Configuration
Check cloudstack.json for localDev.authConfig. If present, use it. Otherwise, detect the auth store pattern from the codebase (see screenshot skill for details).
Prerequisites
The local environment must be running. If not, suggest starting the dev server first.
Process
Step 1: Verify Services Are Up
Check that the expected ports are responding before running browser tests:
# Check API
curl -sf http://localhost:{API_PORT}/health/live > /dev/null 2>&1 && echo "API: UP" || echo "API: DOWN"
# Check Frontend
curl -sf http://localhost:{DEV_PORT} > /dev/null 2>&1 && echo "Frontend: UP" || echo "Frontend: DOWN"
If ORCHESTRATOR is set (e.g., aspire, docker-compose), also check the orchestrator dashboard:
# Only if ORCHESTRATOR_PORT is configured
curl -sf http://localhost:{ORCHESTRATOR_PORT} -k > /dev/null 2>&1 && echo "Orchestrator: UP" || echo "Orchestrator: DOWN"
If services are down, STOP and suggest starting the dev environment.
Step 2: API Health Checks (unless --frontend-only)
# Hit each service health endpoint
curl -sf http://localhost:{API_PORT}/health/ready | python3 -m json.tool 2>/dev/null || echo "Health check failed"
Step 2.5: Authenticate (Frontend only)
Before testing frontend routes, attempt login. Try the UI form flow first:
browser_navigatetohttp://localhost:{DEV_PORT}/loginbrowser_snapshotto find the login form- If a login form is found, fill it with dev credentials from
localDev.authConfigor generic test values browser_wait_forredirect away from/login
If login fails (stays on /login after 5 seconds), fall back to localStorage injection using the auth configuration.
Step 3: Auto-Detect Routes (unless specific URL provided)
Instead of hardcoded routes, detect routes from the project's router configuration:
# Find router config
grep -rl "createBrowserRouter\|RouteObject\|<Route" {FRONTEND_PATH}/src/ 2>/dev/null | head -3
Read the router file and extract all top-level route paths. Always include / (root/dashboard).
If route detection fails, fall back to testing just / and /login.
For each route:
- Navigate using
mcp__playwright__browser_navigate - Wait for the page to settle using
mcp__playwright__browser_wait_for(wait for network idle or a known element) - Snapshot the page using
mcp__playwright__browser_snapshotto check the accessibility tree for content - Check console using
mcp__playwright__browser_console_messagesfor errors - Screenshot (if
--screenshot) usingmcp__playwright__browser_take_screenshot
Step 3.5: Interactive CRUD Flows (only when --interactive)
Skip this step unless --interactive was passed.
Auto-detect CRUD opportunities from the current page:
-
browser_snapshotto find Create/Add/New buttons on the current page -
If a create button is found: a.
browser_clickon the button b.browser_wait_forthe dialog/form to appear c.browser_snapshotto identify form fields d.browser_fill_formwith generic test data (e.g., name:smoke-test-{timestamp}, version:1.0.0) e.browser_clickon the submit button f.browser_network_requests— verify the POST/PUT request returned 2xx g.browser_take_screenshotto capture the result h.browser_snapshotto verify the new item appears in the list -
If list items exist, test the detail flow: a.
browser_clickon the first item row/link b.browser_wait_forthe detail page/panel to load c.browser_snapshotto verify detail content rendered
Step 4: Check for Problems
Flag issues:
- Console errors — any
errorlevel messages in the browser console - Network failures — check
mcp__playwright__browser_network_requestsfor failed requests (4xx/5xx) - Empty pages — snapshot shows no meaningful content
- Auth redirects — unexpected redirects to /login
Step 5: Cleanup
Close the browser session:
mcp__playwright__browser_close
Output Format
## Smoke Test Results
### API Health
| Endpoint | Status |
|----------|--------|
| /health/live | PASS |
| /health/ready | PASS |
### Frontend Routes
| Route | Status | Console Errors | Notes |
|-------|--------|---------------|-------|
| / | PASS | 0 | Dashboard rendered |
| /users | PASS | 0 | List loaded |
| /settings | FAIL | 2 | "TypeError: Cannot read property..." |
### Interactive Flows (if --interactive)
| Flow | Status | Notes |
|------|--------|-------|
| Create Item | PASS | Created "smoke-test-1710345600", visible in list |
| Item Detail | SKIP | No items in list |
### Console Errors
- `/settings`: `TypeError: Cannot read property 'map' of undefined` at settings-page.tsx:42
### Network Failures
- None
### Summary: {PASS / FAIL}
{N routes tested, M passed, K failed}
Guidelines
- This is a fast smoke test, not a comprehensive E2E suite
- Check for obvious breakage, not pixel-perfect rendering
- Console errors are the most valuable signal
- If auth is required and no credentials are available, note which routes redirected to login
- Don't fail on warnings, only on errors
Error Handling
- Services not running: STOP and suggest starting the dev environment before retrying.
- Playwright not available: Suggest installing with
npx playwright installor skip browser tests and fall back tocurl-based health checks only. - Auth required: Note which routes redirected to login and report as "SKIPPED (auth required)" rather than "FAIL".
Related Skills
/add-featureto scaffold the feature, then smoke test it/verify-featurefor targeted verification of specific routes/screenshotfor a quick single-page capture
Gives 0 of the 12 instructions most e2e browser skills give
Counted across 407 of the 410 authors here whose files we hold, read 2026-08-06
- use page object model patternin 35 of 407, across 25 files
- Snapshot to get element refsin 24 of 407, across 14 files
- keep tests independentin 23 of 407, across 18 files
- Interact using refs from the latest snapshotin 23 of 407, across 11 files
- clean up test data after each testin 21 of 407, across 15 files
- test user behavior not implementationin 20 of 407, across 14 files
- quarantine flaky tests explicitlyin 19 of 407, across 10 files
- wait for specific network conditionsin 18 of 407, across 8 files
- re-snapshot after navigation or dom changesin 17 of 407, across 10 files
- Detect running dev servers before writing test codein 17 of 407, across 7 files
- use web-first assertionsin 17 of 407, across 14 files
- capture screenshots or videos on test failurein 17 of 407, across 14 files
Said here and by no other author read
- verify services are running
- check api health endpoints
- authenticate before testing routes
- detect frontend routes from router config
- navigate each route using playwright
- flag console errors and network failures
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.