Help us improve
Share bugs, ideas, or general feedback.
From interhelm
Use when verifying critical user journeys in a running application without screenshots — queries structured /diag/ui/state endpoints for semantic UI state instead of visual inspection.
npx claudepluginhub mistakeknot/interagency-marketplace --plugin interhelmHow this skill is triggered — by the user, by Claude, or both
Slash command
/interhelm:cuj-verificationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use when:
Visually verify implemented features work correctly before marking complete. Use when testing UI changes, verifying web features, or checking user flows work in the browser.
Runs AI-powered adversarial UI testing via the browse CLI — analyzes git diffs, explores full apps, and tests functional correctness, accessibility, responsive layout, and UX heuristics. Use for QA pull requests, auditing accessibility, or exploratory testing.
Verifies frontend changes against spec acceptance criteria using Playwright MCP for browser automation. Automates spec intake, dev server/auth checks, and test runs.
Share bugs, ideas, or general feedback.
Use when:
Do NOT use when:
/diag/ui/stateInstead of taking screenshots to verify UI changes, query the structured UI state endpoint:
app-diag ui # GET /diag/ui/state
Record: active_view, panel states, selections, form values.
Execute the user action via the diagnostic server's /control/* endpoints. This pattern works for actions exposed through control endpoints (restart, reset, step, select, create). For actions that require UI interaction (button clicks, drag-and-drop), you'll need to add corresponding /control/* endpoints first — see the runtime-diagnostics skill for guidance on scaffolding control endpoints.
app-diag ui # GET /diag/ui/state again
Compare before and after states. Verify:
# Step 1: Before state
app-diag ui
# → { "active_view": "world_map", "panels": { "inspector": { "visible": false } } }
# Step 2: Action — select entity via control endpoint
curl -X POST http://localhost:9876/control/select -d '{"entity_id": "country_42"}'
# Step 3: After state
app-diag ui
# → { "active_view": "world_map", "panels": { "inspector": { "visible": true, "selected_entity": "country_42" } } }
# Step 4: Assert
app-diag assert "panels.inspector.visible == true && panels.inspector.selected_entity == 'country_42'"
# → { "result": true }
Token cost comparison:
For CUJs with multiple steps, chain state-before/action/state-after sequences:
# CUJ: "User creates a new entity and verifies it appears"
# Step 1: Verify entity list count before
app-diag assert "simulation.entity_count == 156"
# Step 2: Create entity via control
curl -X POST http://localhost:9876/control/create_entity -d '{"type": "country", "name": "NewCountry"}'
# Step 3: Verify entity count increased
app-diag assert "simulation.entity_count == 157"
# Step 4: Verify entity appears in UI
app-diag assert "panels.entity_list.items | contains('NewCountry')"
# Step 5: Select the new entity
curl -X POST http://localhost:9876/control/select -d '{"entity_name": "NewCountry"}'
# Step 6: Verify inspector shows the new entity
app-diag assert "panels.inspector.selected_entity.name == 'NewCountry'"
Structured state queries don't replace screenshots for:
Use interhelm for functional CUJ verification. Use screenshots for visual verification.