chore: Add sentry-analytics Claude skill

[JoshFerge]

Summary

Adds a Claude Code skill for adding frontend analytics events to the Sentry codebase.

What the skill covers

• Button click analytics - Using analyticsEventKey, analyticsEventName, and analyticsParams props (preferred approach)
• Manual trackAnalytics() - For non-button events like form submissions, effects
• Event type definitions - Where to define types and event maps
• Naming conventions - Event key and Amplitude name formats

Usage

The skill will be automatically triggered when asking Claude to add analytics events. It provides guidance on:

1. Using button props for click tracking (preferred)
2. When to use trackAnalytics() instead
3. How to define event types in seerAnalyticsEvents.tsx or similar
4. Testing with DEBUG_ANALYTICS=1

Test plan

• Verify skill loads correctly with /sentry-analytics
• Ask Claude to add an analytics event and verify it follows the patterns

[JoshFerge]

do this button prop analytic event tracking pick up default params like user id and org and whatnot?

[JoshFerge]

maybe rename to sentry-frontend-analytics?

[JonasBa]

Agree, that would be better!

[JoshFerge]

i assume this is only needed if we don't use the button props stuff?

[JonasBa]

Exactly, but tbh, I'd prefer to just have explicit trackAnalytics calls, it will work cross all different components and be more explicit. These props are only supported on the button component too, which is super wonky from an API consistency pov

[JoshFerge]

gotcha, so maybe it sounds like for simple buttons it makes sense to use them, but if you need any additional props you should use trackAnalyticsEvents in the onclick handler?

[JonasBa]

I'd go even further and just say use the trackAnalyticsEvent function all the time. Nobody ever knows these props exist, and what seems like a convenience thing turns into confusion.

I'd bet that even for simple stuff, people end up calling trackAnalyticsEvent and it's the same reason why people write <Tooltip><Button/></Tooltip> even thought they could use tooltipProps from the button.

[scttcper]

we don't want people to create effects for this since really what you want is a debounce for things like loading. we have a useRouteAnalyticsEventNames and useRouteAnalyticsParams

[scttcper]

i guess that mostly only makes sense for page level analytics, but most are when counting views

[JonasBa]

@JoshFerge I would add one thing here which is to guide AI away from useEffect and observing state, and to instead add trackAnalyticsEvent to the existing callbacks.

For example

const [toggle, setToggle] = useState()

<input type="radio" onChange={() => setToggle(!toggle)}

shouldn't become (also likely unwanted as it will fire on initial render)

const [toggle, setToggle] = useState();

useEffect(() => trackAnalytics(...), [toggle])

<input type="radio" onChange={() => setToggle(!toggle)}/>

but should instead just be

const [toggle, setToggle] = useState()

<input type="radio" onChange={() => {
	trackAnalytics(!toggle)
	setToggle(!toggle)
}}/>