frontend-observability

Frontend Observability (the field side)

When to Use

Use this skill when you need a portable, framework-agnostic field-side observability system for any React or React Native app. Establishes one typed event taxonomy (canonical event-name constants, never inline strings), a best-effort non-blocking provider fan-out so a failing or absent analytics provider can never...

Portable skill — readable by Claude Code, OpenCode, Codex, Cursor, Windsurf, and others.

This skill describes a field-side observability system — event taxonomy, provider fan-out,

real-user vitals, error reporting, consent — not a dashboard or a specific vendor. It is the

field complement to the frontend-lighthouse skill: Lighthouse is the _lab_ gate (synthetic,

pre-merge); this is the _field_ (what real users actually experience). It lives in a

services/analytics/ module per the frontend-architecture skill.

The goal: you can answer "what are real users doing, and what are they experiencing?" — with a typed event vocabulary (no stringly-typed track("clicked_thing") scattered everywhere), a fan-out that is best-effort (a broken provider never breaks the app), real Core Web Vitals from the field, and consent respected before anything fires.

---

0. The five core ideas

1. Events are a typed vocabulary. Event names are canonical constants with a union type