Cursor's Internal Guide for Building with Cursor
A tutorial by Cursor. Featured in the OTF curated resource library.
Cursor on Cursor: The Meta Story
There's something uniquely instructive about watching a team use their own product to build that product. The Cursor team uses Cursor for 100% of their development — and they've developed specific workflows that leverage features most users overlook.
This guide distills the internal practices they've shared publicly. It's not about basic features — it's about the specific patterns that make their engineers 3-5x more productive than before they built the tool.
The core insight: Cursor isn't just a faster way to type code. It's a thinking partner that changes how you approach problems. The team structures their entire development process around AI collaboration, from planning through implementation to review.
Core Workflows
The Cursor team uses these workflows daily for every feature and bug fix.
Cmd+K for inline edits
The most-used feature internally. Select code, press Cmd+K, and describe the change. The team uses this for everything from renaming variables to refactoring entire functions. The key: be specific about the change you want, not vague.
Chat for exploration and planning
Before writing code, use the chat panel to discuss the approach. 'How should I implement X given the current architecture?' The chat sees your entire codebase and gives architecture-aware suggestions.
Composer for multi-file features
For changes that span multiple files, Composer is the go-to. Describe the full feature, and Cursor plans and implements changes across your codebase. The team uses this for 80% of new feature development.
Tab completion for flow state
For smaller edits and quick changes, tab completion keeps you in flow. The team configures it aggressively — accepting suggestions quickly and iterating if needed rather than waiting for the perfect suggestion.
Prompt Engineering in the IDE
Reference Files with @
Use @ to reference specific files in your prompts: '@src/lib/api.ts add a new endpoint for tools.' This focuses the AI on the right context and produces more accurate edits.
Use .cursorrules Extensively
The Cursor team maintains a detailed .cursorrules file with their coding conventions, architecture patterns, and common pitfalls. This file is read with every prompt and dramatically improves output consistency.
Be Explicit About Constraints
Instead of 'add error handling', say 'add try/catch with proper error types, logging to our error service, and user-facing error messages.' Explicit constraints produce production-ready code.
Ask for Explanations
Before accepting complex changes, ask 'explain why you made this choice.' Understanding the reasoning helps you catch incorrect assumptions and learn better patterns.
Advanced Features They Rely On
Codebase Indexing
Keep your codebase indexed for maximum context. The team ensures their index is always up-to-date so chat and Composer have full visibility into the project structure and dependencies.
Custom Models
The team switches between models based on task complexity. Fast models for simple edits and autocompletion, powerful models for architecture decisions and complex features.
Multi-File Diffs
Review all changes across files before accepting. The team treats Composer output like a PR — reviewing the full diff, checking for unintended changes, and verifying consistency.
Team-Level Practices
Beyond individual workflows, the Cursor team has developed team-level practices:
Shared .cursorrules: The entire team uses the same rules file, committed to the repo. When conventions change, the rules file is updated in a PR and reviewed by the team.
Prompt Libraries: Common prompts are documented and shared. New team members get a 'prompt starter kit' with patterns for their most frequent tasks.
Review Standards: The team has specific review criteria for AI-generated code — checking for edge cases, error handling, and test coverage that agents sometimes miss.
Feedback Loop: When an AI interaction produces poor output, they note the prompt and result. These failures inform improvements to .cursorrules and shared prompt patterns.
The result: a team where every engineer operates at a significantly higher velocity, with consistent quality enforced by shared tooling and practices.
