My Real Cursor + Claude Workflow After 18 Months of Daily Use

Most "Cursor tips" articles are surface-level. "Use Cmd+K." "Try @Codebase." Yes, those work. But after 18 months of using Cursor + Claude on real client projects, I've found patterns that matter more than features.

Here are the ones that actually compound.

1. Plan before you prompt

The single biggest mistake: opening Cursor and immediately prompting "build me a contact form."

Better:

1. Write a 5-line plan in plain English first
2. Paste the plan to Claude in a separate window and ask: "What am I missing?"
3. Then prompt Cursor with the refined plan

This catches design flaws before they become refactors.

2. The "rules" file changes everything

In your project root, create .cursor/rules/general.mdc:

Project rules

Always use TypeScript strict mode All forms must use Server Actions, not API routes All images must use next/image with width and height Database queries should be in /lib/db/, never in components Tests live next to the file: foo.ts → foo.test.ts Commit messages follow conventional commits

When generating code:

Prefer Server Components, only "use client" when needed Always handle loading and error states Use early returns over nested if/else

Cursor reads this on every prompt. You stop having to remind it of project conventions.

3. Reference real files, not concepts

Bad prompt:

"Make a card component"

Good prompt:

"Create a TestimonialCard component matching the style of @components/ProjectCard.tsx but with a quote, author name, and small avatar"

The @filename reference forces Cursor to actually read your existing code patterns. Output quality jumps 5x.

4. Use Claude for thinking, Cursor for typing

This is the workflow most people get wrong.

Cursor is amazing for: writing code, refactoring, fixing types, generating boilerplate.

Claude (separate window) is amazing for: architecture decisions, debugging tricky bugs, planning sprints, reviewing your code.

Don't conflate them. When stuck, switch tools.

5. The "explain this to me" debugging pattern

When something breaks and you can't figure out why:

1. Copy the error + the relevant code
2. Paste to Claude
3. Prompt: "Explain what this code is doing line by line. Then identify which assumption might be wrong."

90% of the time, Claude's explanation reveals the bug to you before Claude even points it out. The act of having it explained is what unlocks your brain.

6. Don't let Cursor write tests for code it just wrote

Cursor will happily generate tests that pass — by testing the buggy behavior. Always.

Better: write tests yourself for new functionality. Use Cursor for boring repetitive test code (different valid inputs, edge cases).

7. The 3-file pattern for new features

When building anything significant, I open 3 tabs in Cursor:

1. The file I'm building (the feature)
2. A similar existing file (the pattern)
3. The types/schema file (the contract)

Then I prompt: "Build [feature] following the pattern from @file2 and the types in @file3."

This produces idiomatic code that fits the codebase, not generic AI-flavored code.

What I stopped doing

• Asking Cursor open-ended questions ("how should I structure this?")
• Trusting AI-generated regex without testing
• Letting Cursor refactor anything > 200 lines without supervision
• Prompting in the middle of the file (always start with what's needed)

The compound effect

None of these tips alone is a 10x. But layered together, they're the difference between "AI helped me write this" and "AI made me a senior engineer's pair programmer."

The developers who'll thrive in 2026-2027 aren't the ones who use Cursor. They're the ones who built habits around it.