Anysphere
Cursor is an AI code editor, not a model. To prompt it well: reference the right files, set project rules, review diffs.
Cursor is an AI code editor made by Anysphere. It is listed alongside the assistants on this site because people paste prompts into it, but it is a different kind of product: Cursor is not a model. It is an editor that sends your request, together with parts of your codebase, to a language model you select, and then applies the result to your files.
That distinction shapes how to prompt it. In a chat assistant, the prompt is nearly everything the model sees. In Cursor, your message is one input among several. The editor can also include open files, files you reference explicitly, project-level rules, and search results from the repository. Getting good output is therefore mostly a matter of managing that context: making sure the relevant code is in view and irrelevant code is not.
It also changes what the output is. A reply in a chat window is text you read. A reply in Cursor may be an edit to a file, a set of changes across several files, or a command to run. The cost of a vague prompt is higher, because a wrong answer can become a wrong change. Small, well-defined requests that you can review as a diff are safer than broad ones.
The prompts on this site list Cursor only for coding work done inside a repository, such as refactoring, writing tests, debugging and code review. Use them as the task description, and let the editor supply the code itself by referencing the files involved instead of pasting them into placeholders.
Because Cursor relies on underlying models that vary, the model-specific pages for whichever one you have selected are relevant too. Editor features, modes and plans change regularly and are not detailed here; Cursor's own documentation is the reference for current behavior.
Reference the specific files, functions or folders the task concerns, using the editor's mechanism for attaching context, so the model works from the real code and not from a guess about it. Name the file where the change should happen and any file that shows the pattern to follow. Leaving context to chance is the most common reason for edits that do not fit the codebase.
Things that are true for every task in a repository, such as the framework and language version in use, naming conventions, the testing approach and directories that must not be touched, belong in the project's rules file and not in each prompt. Keep those rules short, concrete and current. A long rules file full of general advice competes for attention with the task itself.
Describe a single outcome with a clear finish line: the behavior expected, the files in scope, and what must stay unchanged. For larger work, ask for a plan first, agree it, then have the steps carried out one by one. Each step then produces a diff small enough to read properly, and a mistake is caught before more changes are built on it.
The repository shows what exists; it does not show what you intend. Say whether public interfaces may change, whether new dependencies are acceptable, which behavior is covered by tests and must be preserved, and how the result will be verified. If there is an error message or failing test, include its exact text so the request is anchored to something observable.
Read the diff before accepting it, run the tests, and use version control so any change can be reverted. Be especially careful with commands the editor proposes to run and with edits outside the files you named. If a result is wrong, a fresh conversation with a tighter prompt and better context often works better than a long thread of corrections.
These prompts are expected to work with Cursor based on their structure. Check each prompt page for its testing status; see how compatibility is labelled.
Reviews a diff the way a careful senior engineer would: intent first, findings ranked by severity, each tied to a line with a suggested fix.
Works from your own field and lab data to rank likely causes of poor LCP, INP or CLS, with a way to confirm each one before you change code.
A plan-then-build prompt for App Router work: routes, server and client boundaries, caching, mutations and authorization, approved before any code.
Makes the model plan components, state and effects before coding, then deliver complete files, tests and a list of what it assumed.
Designs a relational schema from your entities, rules and real queries: relationships, DDL, constraints and indexes that each trace to a query.
Builds a layout with Grid, Flexbox and container queries that adapts to its content, with the reasoning and the edge cases to test.
Give the model the error, the code and what you expected. It ranks likely causes by evidence, tells you how to confirm each, and proposes a minimal fix.
Restructures code in small, named steps while holding its observable behavior fixed, and reports anything it could not prove equivalent.
A contract-first prompt: the model fixes the signature, types and error behavior of a function or module before it writes the implementation.
Turns a plain-language spec into a complete, typed Python script or module, with assumptions, run commands and edge cases listed separately.
Produces a case inventory first, then readable tests that check behavior at the boundaries, with suspected bugs flagged instead of encoded as passing.