rum-tracking
SolidGuides product analytics and RUM (Real User Monitoring) event tracking in web (React/Next.js) and mobile (React Native/Expo) apps. Decides what user interactions are valuable to capture, what's noise, what's PII to avoid, and how to implement, audit, update, and remove tracking code cleanly. Covers event naming, property schemas, tracking plans, GDPR/CCPA/DPDPA compliance, OpenTelemetry semantic conventions for browser and mobile RUM, and platforms (PostHog, Segment, Mixpanel, Amplitude, Datadog RUM, Sentry, OTel, Dash0). Modes: guide (default), implement, audit, remove, plan. Triggers on "track this event", "add analytics", "what should I track", "is this PII", "tracking plan", "remove tracking", "audit analytics", "/rum-tracking".
Install
Quality Score: 84/100
Skill Content
Details
- Author
- mthines
- Repository
- mthines/agent-skills
- Created
- 3 months ago
- Last Updated
- 2 days ago
- Language
- TypeScript
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
dt-obs-frontends
Real User Monitoring (RUM) on Dynatrace — web and mobile frontends. Core Web Vitals, user sessions, page performance, mobile crashes, frontend errors, and frontend-backend linking. Query via `user.events`, `user.sessions`, and `dt.frontend.*` metrics. Does NOT cover synthetic monitoring (HTTP/browser/network checks) — that's a separate domain.
tracking-plan
Designs the event tracking plan for a feature or product area — the event taxonomy, naming convention, properties, and QA checklist that make a metric answerable later. Use when a PM says "what should we instrument", "write a tracking plan", "what events do we need", "we can't answer that from the data", "define the analytics for this feature", or is about to ship something with no way to tell whether it worked.
rook-triage
Use when triaging rook (github.com/rook/*) issues or PRs — grooming or clearing the backlog, labeling or categorizing issues, finding duplicate issues, cross-linking an issue to a PR (or a PR to the issue it fixes), checking what info a bug report is missing, deciding who should review a PR or requesting reviewers, or refreshing the routing knowledge base ("kb refresh"). Scope with "issues", "prs", or "both"; single items as "issue N" / "pr N". Deep code review routes to rook-code-review.