Integrating Cursor rules

[daniloc]

Adding Cursor rules files is pretty straightforward. This could be handy because the agent is liable to take random initiative and break perfectly working things. Hypothesis: A bit of static error correction built into the project will guard against the worst drift.

Even more interesting: the wizard could keep the rules up to date as our docs evolve.

This pull:

• Detects whether we're in a Cursor session by looking for the CURSOR_TRACE_ID environment variable
• Includes raw rules files in the wizard's build
• Copies that file into a project according to the selected framework

[joshsny]

Left some comments, this is going to be a great addition 🙌

[joshsny]

I think here we can just ask it to be consistent, rather than consulting with the developer as we want things to move fairly fast when adding analytics

[daniloc]

Okay so that's a piece where moving fast could lead the developer right over a cliff. Two essential pieces of guidance to not create a Failed Integration:

• collect all platforms in a single project (so web, iOS, android for example)
• use consistent event names across those platforms

My big concern from talking to the sales crew is how much event naming drift causes problems. But maybe the above is the wrong way to address this. What do you think?

[joshsny]

Sounds good, let's keep it and try it out!

FYI I'll probably be working on a custom version of instrumenting events so will be nice to see how these cursor rules play out as a first step

[joshsny]

For properties, I'd suggest we don't enforce the enum constraint as it makes code edits more complex for the LLM, but to encourage adding as many useful properties as possible. Thoughts?

[daniloc]

Okay so I am deeply allergic to using the same string literal more than once, because if you ever have to change its value, you don't have a single source of truth to work from. but maybe that doesn't matter as much for custom properties. If you're setting the same property in multiple places maybe that is itself the problem.

On "useful properties," hmm, agree it would be nice but I wonder how to constrain that given how stupid these tools are when taking initiative lol

[joshsny]

Maybe you can take these rules for a spin in cursor and see whether it pulls out the properties well?

If it does, then the end result would be great. My concern was if this will slow it down and distract it as it's switching between writing to different files a lot 🤷‍♂️

[daniloc]

So the approach that it took was to create a new file dedicated to these constants, which was perfect. That's narrow enough not to clog the context window, and the context it does consume is very helpful

It would also be handy to then be able to @ the file in the future:

"All the names you need to use or update are in @analytics.ts" or what have you

I wonder if that should be an explicit part of the prompt, making that file.

[joshsny]

This we can probably leave, as by default the installation does not identify from the wizard, so the LLM is unlikely to add it unless there is clearly auth related code, in which case we usually want to encourage identification.

I think it'd be useful to prompt the user around how to identify well (e.g. when the user logs in) and remember to reset when they logout etc.

[daniloc]

Okay, so here's a simple but working starting place, evolved based on the above discussion.

I've debugged it extensively (we need to store the files as .md instead of .mdc otherwise using cursor OURSELVES will cause the frontmatter for driving the UI to be mangled, and the rules don't get applied in the target projects)

Took the rules THEMSELVES for a test drive and:

• Cursor did act on them when I made a PostHog-themed request
• The agent productively followed their lead

Playing with this, I think it's probably helpful to start with a light touch and then evolve the rules files as we learn more from feedback.

That said, any other obvious cues we'd want to include to support other products/features?