web-runtime-verify

Serves a built frontend on an ephemeral port and gates runtime behavior with a verification battery.

6|Updated Jul 10, 2026
One-click install
npx skills add https://github.com/Mozurok/fhorja.dev --skill web-runtime-verify-mozurok
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: web-runtime-verify
Source: https://github.com/Mozurok/fhorja.dev/tree/main/.claude/skills/web-runtime-verify
Command: npx skills add https://github.com/Mozurok/fhorja.dev --skill web-runtime-verify-mozurok

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Static checks cannot catch runtime failures like a stale server serving yesterday's build, horizontal overflow at 320px, console errors on load, or keyboard focus traps. This Skill serves the built frontend and verifies its actual runtime behavior before a slice is closed, producing evidence-backed PASS/FAIL/BLOCKED verdicts instead of unverified claims. ## Core Features & Use Cases - Page identity assertion with recovery: Asserts the served page is the right one before any other check, automatically re-binding to a fresh free port on a collision or stale server. - Runtime verification battery: Probes horizontal overflow at 320/768/1280/2560 px, walks keyboard focus, captures console errors, and runs Lighthouse and axe when available, reporting honest n/a when tools are absent. - Evidence-based gate decision: Classifies findings with a taxonomy (CONSOLE_ERROR, OVERFLOW, FOCUS_DEFECT, etc.), writes a WEB_RUNTIME_VERIFY.md report with screenshots, and routes failures to the appropriate fix command. - Use Case: After implementing a responsive pricing page slice, run this gate to confirm the built page loads without console errors, shows no overflow at mobile widths, and passes its acceptance criteria before closing the slice. ## Quick Start Verify the runtime behavior of my built frontend in the dist folder against the slice's acceptance criteria and give me a PASS or FAIL verdict.

Frequently Asked Questions about web-runtime-verify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a built frontend's runtime behavior before closing a task?▼

Serve the build output on an ephemeral free port, assert the page identity marker first, then run a battery covering overflow at 320-2560 px, keyboard focus, console errors, and Lighthouse/axe when available. The run ends in a PASS, FAIL, or BLOCKED gate decision backed by quoted evidence.

How to detect a stale server serving the wrong page during testing?▼

Assert a page-identity marker (title, unique selector, or text snippet) before any other check. If the marker is absent or the port was occupied, re-bind to a fresh free port and retry once; a marker still missing after recovery is a real FAIL with the fetched evidence quoted.

Does this runtime gate replace Lighthouse or axe accessibility audits?▼

No. It runs Lighthouse and axe when available and reports their measurements, but numeric performance budgets belong to a separate performance-budget gate, and accessibility clusters route to a dedicated a11y-audit command. Missing tools are reported honestly as n/a.

Can this command fix the frontend issues it finds?▼

No. It only serves, verifies, and routes. A FAIL routes to incident-triage for unclear causes, implement-slice-complement for bounded known fixes, or a11y-audit for accessibility clusters; it never writes or modifies code itself.

Why must the verification server use an ephemeral port instead of a fixed one?▼

A hardcoded port risks colliding with a stale server serving an old build, which makes every subsequent check verify the wrong page. An OS-assigned or probed free port guarantees the served origin is the current build, and the real port is reported as evidence.