メニュー
Verifies web changes by exercising them in a real browser with DevTools — console, network, interaction, states, and layout. Use after any UI or front-end change, when debugging browser-only bugs, or before claiming a web change is done.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | browser-checks |
| description | Verifies web changes by exercising them in a real browser with DevTools — console, network, interaction, states, and layout. Use after any UI or front-end change, when debugging browser-only bugs, or before claiming a web change is done. |
Code that looks right and code that works in the browser are different claims. Compilation, unit tests, and static review cannot prove runtime behavior, layout, network timing, or interaction. For anything the browser renders or runs, prove it by driving the real page: load it, interact, watch the console and network, and capture evidence.
Run the browser checks checklist alongside this process. For accessibility verification in the browser, finish with [[accessibility]]. For systematic debugging when something fails, switch to [[fault-recovery]]. For UI quality beyond verification, see [[ui-craft]].
Skip as the primary skill when the change has no browser surface (pure types, CLI tooling, unrelated backend-only logic with no UI impact).
Work in order. Stop and diagnose before moving on if something is broken — a red console often invalidates everything else.
/dashboard may still break a guest on /.The console is the app's voice. Read it before clicking anything else.
If the console isn't clean, fix or explain before claiming done.
What the UI shows and what the server returned are often different stories.
Don't eyeball the static render — drive the flow a user would.
The happy path is the easy 60%. Users hit the rest first.
| State | What to confirm |
|---|---|
| Loading | Skeleton/spinner shows; no flash of wrong content; no layout jump when data arrives |
| Empty | Meaningful empty message and next action — not a blank screen |
| Error | Error is visible, readable, recoverable; failed network doesn't leave a broken half-UI |
| Partial | Pagination, truncated lists, optimistic updates behave correctly |
| Overflow | Long names, large numbers, many tags — layout doesn't break |
Simulate failures when relevant: DevTools offline, block a request, or use a bad API response to confirm error handling.
If layout, styling, or global CSS changed:
Rotate or resize once; you don't need every device, but one narrow and one wide catches most regressions.
Full a11y is [[accessibility]]; in browser-checks, do a fast sanity pass:
"Should work" is not evidence. Capture something shareable:
Attach proof in the PR or ticket so reviewers and future-you can trust the claim.
If the check surfaces a bug:
Meta-skill that routes a task to the right engineering skill. Load this at the start of a session or when unsure which skill applies — it maps intent to the process that should govern the work.
Catches breaking changes between services before they ship, by testing the contract each consumer actually depends on instead of spinning up the whole system. Use when services deploy independently, when a provider API change could break a consumer, or when end-to-end integration tests are too slow and flaky to guard every service boundary.
Proves whether a change actually moves the metric, with a valid A/B test instead of a guess — a hypothesis, a primary metric, a pre-computed sample size, guardrail metrics, and an honest readout. Use when shipping a change meant to improve a number (conversion, retention, performance), running an A/B or holdout, or deciding whether a feature "worked."
Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt.
Finds security risks at design time — before code exists — by mapping the system, enumerating how it could be attacked, and deciding what to do about each threat. Use when designing a feature that touches auth, data, money, or external input, when changing a trust boundary, or when a security-sensitive change needs a structured risk pass rather than a code-level review.
Designs durable, curated memory that an agent carries across sessions — what to persist, how to scope and retrieve it, and how to stop it from drifting or poisoning later runs. Use when an agent needs to remember decisions, preferences, or project facts beyond one context window, or when stale/over-generalized memory is corrupting its behavior.