← Back to blog

Setting up Cursor like a pro: a frontend developer's guide

4 min read

Most developers install Cursor, use the defaults, and wonder why it keeps suggesting the wrong patterns. The problem isn't the AI — it's that you haven't told it how you work yet.

If you've switched to Cursor and still feel like you're just using a fancier VS Code, you're probably not getting the most out of it. The AI completions are great by default — but the real gains come when you configure Cursor to understand your specific stack, your component patterns, and the way your team writes code. Here's how to actually set it up properly.

Rules: stop repeating yourself in every prompt

How many times have you typed "use TypeScript", "don't use default exports", or "write this as a functional component" into a chat window? Rules eliminate that repetition. They're persistent instructions that Cursor follows across every session, without you having to ask.

There are two places to set them. Global rules live in Cursor Settings under Rules for AI — these travel with you across every project. Your project-level rules live in a .cursorrules file at the repo root, and this is where it gets interesting for frontend teams.

A well-written .cursorrules file tells Cursor everything it needs to know about your project upfront: you're using React 18 with TypeScript, Tailwind for styling, React Query for data fetching, and Vitest for tests. You prefer composable hooks over large components, you keep business logic out of UI files, and you name event handler props with the on prefix. That's not a vague style guide — that's a working context that shapes every suggestion Cursor makes.

Commit your .cursorrules file to version control. Every developer on your team — and every AI session — will benefit from it automatically.

Be specific with rules. "Write good components" does nothing. "Keep components under 150 lines — extract logic into custom hooks if they grow beyond that" gives Cursor something actionable to work with.

Skills: giving Cursor the right context for the task

Even the best AI can't give you great suggestions about your internal design system if it has never seen it. Skills — the context you bring into a session — are how you close that gap.

The @Docs feature is criminally underused. Reference a library directly in chat and Cursor pulls in the relevant documentation before responding. Working with a tricky Framer Motion API? @Docs it. Debugging a React Query edge case? Same. This is especially powerful for packages that have changed significantly since the model's training cutoff.

For your own codebase, build a /.cursor folder and fill it with focused markdown files. One for your component architecture, one for your form patterns using React Hook Form, one for how you structure API calls. Keep each file tight and specific — a 200-line doc on one topic will serve you far better than a sprawling catch-all reference.

When you're in a session, use @file to pull in the relevant skill for the task at hand. Working on the design system? Reference your component conventions doc. Writing a new page? Pull in your routing and data fetching patterns. Think of it as giving Cursor a targeted briefing before it writes any code.

Memories: Cursor that learns as you ship

Cursor's memory features let you persist decisions across sessions without manually re-explaining your setup every time. When you establish a pattern — say, how you structure a feature folder, or how you handle optimistic UI updates — you can save that as a memory so it informs future sessions automatically.

This is particularly powerful for teams. Shared memories mean a new developer pairing with Cursor gets the same contextual guidance as a senior who's been on the project for a year. Decisions that would otherwise live only in Slack threads or someone's head become part of how the AI assists across the whole codebase.

Treat memories like lightweight ADRs (architecture decision records). When you make a meaningful call — "we're using Zustand for global state but React Query's cache for server state, and they don't overlap" — capture it. Future-you, and future teammates, will thank you when Cursor doesn't suggest the wrong approach six weeks later.

Review your memories periodically. A decision that made sense six months ago might conflict with where your stack has evolved — stale memories can be just as harmful as no memories at all.

Putting it all together

The developers who get the most out of Cursor aren't necessarily using more advanced prompts — they've just done the upfront work to make their environment smart. Rules handle your standards automatically. Skills give Cursor the right context for the task at hand. Memories preserve decisions so you're not starting from scratch every session.

Set these up once, keep them maintained, and Cursor stops feeling like a clever autocomplete and starts feeling like a collaborator who actually knows your codebase.