Frontend report triage

Use this skill as the front door for ambiguous or multi-symptom frontend reports. Do not load every sibling skill by default. First classify the report, identify evidence gaps, and route the smallest useful set of follow-up skills.

Triage workflow

1. Extract report facts — user-visible symptom, environment, route/page, device/browser/WebView, reproduction steps, expected vs actual behavior, logs/screenshots/videos, and recent changes.
2. Separate evidence channels — layout, paint, hit-test, DOM, accessibility tree, URL/router state, network/cache/stream, storage, iframe/WebView messages, delivered policies/headers, locale/input behavior, date/time, validation state, runtime scripts, exported files, performance traces, and design reference.
3. Score likely failure classes — mark each class likely, possible, or unlikely with one short reason.
4. Pick follow-up skills — choose at most 3 unless the user explicitly asks for a broad audit. Prefer the most specific runtime evidence over generic categories.
5. Ask for missing evidence only when needed — if the next safe step is inspection, inspect. Ask for screenshots/videos/URLs/logs only when they would change the route or reduce risk.
6. Hand off quickly — if one sibling skill clearly owns the issue, name it and use that skill next.

Failure class map