Frontend testing and debugging

Own the visual diagnosis and fix loop. Reuse project testing infrastructure for repeatable execution, sessions and reports. This skill works independently of the QA plugin.

Choose the flow and execution path

1. Identify the entry route, user action and expected visible result. Inspect repository scripts and running servers before asking for a missing URL. Keep the requested host exact.
2. Read project testing guidance and look for an existing journey covering the change. Run that journey first. When the QA plugin and project configuration are available, follow the project's QA skill and use qa:run-qa for execution, session recovery, telemetry isolation and cleanup.
3. Without project QA journeys, use the repository's existing browser or e2e workflow. For interactive investigation, choose an available browser tool and read its current instructions. Do not assume a particular plugin or API exists. Respect the user's browser preference and avoid taking focus during background work.
4. If no suitable workflow exists, use a temporary diagnostic script outside committed source. Add dependencies only when required by the task and permitted by the user. Report unavailable access or runtime support as a specific limitation.

Interactive inspection is useful for new visual issues and failed journeys. It does not replace a failing regression with an easier smoke check. Before visiting production, use the project's analytics isolation and test-account rules. If those are absent, prefer a local or staging target for diagnostic traffic.

Inspect, fix and verify

Confirm the intended URL and meaningful rendered content. Check relevant console errors and framework overlays before diagnosing layout. Exercise the target interaction and observe its result through visible state, navigation or persisted application behavior.