operational-browser-verification

Verify manager-facing operational workflows in a real browser with scoped fixtures and evidence reports.

Updated Jun 15, 2026
One-click install
npx skills add https://github.com/ravenslight2010/Production-run-calculator --skill operational-browser-verification-ravenslight2010
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: operational-browser-verification
Source: https://github.com/ravenslight2010/Production-run-calculator/tree/main/.agents/skills/operational-browser-verification
Command: npx skills add https://github.com/ravenslight2010/Production-run-calculator --skill operational-browser-verification-ravenslight2010

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Unit, API, and integration tests cannot prove that a manager-facing workflow actually works end to end in a browser. This Skill provides a bounded, evidence-driven browser verification process for operational journeys like queue actions, import-review reopening, sync diagnostics, and reload persistence. ## Core Features & Use Cases - Required Test-Plan Contract: Enforces a complete plan with unique fixtures, authentication role, facility scope, viewport, navigation path, and expected evidence before any browser run. - Operational Journey Checks: Covers live-station run switching, manager action queues, import-history reopening, sync diagnostics with stale-update rejection, reload persistence, and workflow startup health. - Structured Evidence Reporting: Produces a PASS/FAIL/BLOCKED report with screenshots, console and backend log review, and failure classification as application defect, test/setup defect, or environment blocked. - Use Case: A manager claims a scoped queue item and opens its source workflow; the Skill verifies the claim persists after reload, the destination is correct, and a non-manager account is denied. ## Quick Start Ask the agent to verify that a manager can claim a scoped action-queue item and reopen its source workflow in the browser, with evidence of persistence after reload.

Frequently Asked Questions about operational-browser-verification

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

FAQPage Schema
How do I verify a manager workflow in a real browser?

Write a test plan covering goal, unique fixtures, authentication role, facility scope, viewport, navigation path, and expected evidence, then run it through the Playwright testing subagent. End with a PASS/FAIL/BLOCKED report including screenshots and log review.

When should I use browser verification instead of unit or API tests?

Use browser verification when the risk involves user-visible behavior like queue actions, review reopening, sync status, or reload persistence. Route payload contracts, sync invariants, and parser correctness to API, integration, or unit tests instead.

Does this support testing at mobile viewports?

Responsive web behavior at an explicit viewport such as 390×844 is in scope. Real mobile hardware testing is out of scope unless the request explicitly requires device-only behavior.

How are stale-update conflicts tested in the browser?

Use two browser contexts or a controlled stale version stamp: make the older write, verify it is visibly rejected, and confirm the newer value remains after reload. A stale-write rejection must never be reported as a silent success.

What happens when the app or workflow cannot start?

The run is classified as environment blocked. Record the first actionable error, preserve logs, report BLOCKED, and stop mutating fixtures until the underlying setup or environment issue is fixed.