Cursor Prompts: 20 Copy-Ready Prompts by Job

"Fix the login bug" is not a bad prompt because it's short. It's bad because Agent has to guess which bug, what fixed means and when to stop. Most of the prompts here do one boring thing about that: they give Cursor a check it can run. These are written for an existing codebase, not a blank project. If you're starting from zero, our vibe coding prompts for a SaaS MVP are a better fit.

How to use these prompts

Open Agent with Cmd+I (Ctrl+I on Windows and Linux), then press Shift+Tab or use the mode picker to switch modes. Each prompt below names the mode it was written for. In short:

• Ask is read-only. It answers questions and explores code without edits.
• Plan researches your code, asks clarifying questions and writes a plan you can edit before building. Click "Save to workspace" to keep it with the project.
• Agent edits files and runs terminal commands. It creates checkpoints before significant changes, so you can restore files if it takes a wrong turn. Use Git for anything permanent.
• Debug forms hypotheses, adds logging, asks you to reproduce the bug and fixes what the evidence shows.

Then add context. Type @ to attach files and folders, @Terminals, @Chats, @Branch or @Browser, and drop in a screenshot for UI work. Tag a file when you know it's the right one. When you don't, leave it out, because Agent can search for it. Our prompting techniques for code quality go deeper on why constraints work; this page is the Cursor-specific, paste-it-now version.

Which prompt for which job

Prompts to understand a codebase

1. Trace a feature end to end (Ask)

Run this before you change code you did not write. Ask mode can't edit anything, so it is a safe first move.

Trace what happens when [user action, e.g. a customer applies a discount code], from the UI event to the database write.
List each file and function in order, with one line on what it does.
Mark anything you are inferring rather than reading directly from the code.

2. Get oriented for a first task (Ask)

Replaces the first hour of poking around a new repository.

I am new to this repository and my first task is [task].
Tell me: how to run the app locally, how to run the tests, where [area of the product] lives, and which existing file is the best example to copy.
Give the file path for every answer. If the repository does not answer a question, say so instead of guessing.

Prompts to plan a feature

Cursor's docs recommend Plan Mode for complex features, tasks that touch many files and unclear requirements. For a quick change, or one you've made many times, skip straight to Agent.

3. Plan a feature with hard questions first (Plan)

The opening prompt for anything that touches several files. It forces a definition of done before any code exists.

I want to add [feature] for [type of user].
Done means: [observable behavior, e.g. an admin can export paid invoices as CSV from the billing page].
Out of scope: [list].
Research the code, then ask me up to 5 questions, only where a wrong assumption would be expensive to undo.
Then write a plan with the files to change, the order of the work, any data or API changes, and the tests that will prove it works.

4. Compare two approaches (Plan)

For decisions where the expensive part is picking wrong, such as a schema or a new dependency.

We need [capability]. Compare [option A] and [option B] for this codebase.
For each one, list the files touched, the migration work, the failure modes and what gets harder six months from now.
Recommend one and tell me what fact would change your recommendation.
Do not write the plan until I pick.

5. Cut the plan down (Plan)

Plans tend to grow. Run this before you click build.

Review the plan above against this goal: [goal in one sentence].
Remove every step the goal does not need and list what you removed.
Split what is left into steps I can review and commit separately, and give each step a command or manual check that shows it worked.

Prompts to build and change code

6. Make one scoped change (Agent)

The everyday prompt. The last two lines stop most of the drive-by edits.

In @[file], change [current behavior] so that [new behavior].
Follow the pattern in @[example file].
Edit only what this change needs. If another file looks wrong, list it at the end instead of fixing it.
When you finish, run [test command] and show me the result.

7. Build one plan step at a time (Agent)

Keeps a long plan reviewable, and gives you a clean checkpoint between steps.

Build step [number] of the plan in @[plan file]. Do not start the next step.
Then run [typecheck command] and [test command].
Finish with what changed, what you skipped and anything in the plan that turned out to be wrong.

8. Add an endpoint that matches the codebase (Agent)

Pointing at a real example beats describing your conventions in prose.

Add [HTTP method] [path] that [what it does].
Copy the structure of @[similar route file]: validation, auth check, error format and logging.
Input: [fields and types]. Response: [shape]. Errors: [each case and its status code].
Add tests for the success case, each error and a caller without permission.
Run the tests and fix what fails.

9. Turn a mockup into a component (Agent, with an image)

Drag or paste the image into the chat input. Agent can use its browser tool to check the running result.

Implement the attached mockup as [component name] in @[folder].
Reuse existing components from @[components folder] and the design tokens in @[tokens file]. Do not add a new UI library.
Add loading, empty and error states, and tell me what you assumed for them.
Open [local URL] in the browser, compare the result with the mockup at [desktop width] and [mobile width], and fix the differences.

Prompts to debug

10. Find the cause of a reproducible bug (Debug)

Debug Mode is built for this: hypotheses, logging, then a fix based on runtime evidence. Your job is to reproduce the bug when asked.

Bug: when I [exact steps], I expect [expected result] but get [actual result].
It started around [date, release or commit, if known]. Error text: [paste it].
Give me at least two hypotheses before changing any code, and exact steps to reproduce.
Fix only the confirmed cause, then remove the logging you added.

11. Fix a failing test honestly (Agent)

The instruction not to weaken the test is the whole point of this prompt.

@Terminals shows [test name] failing.
Work out whether the test or the code is wrong and explain why before you change either.
Do not delete, skip or loosen the test unless you have shown it is wrong and I agree.
After the fix, run that test and the rest of its file.

12. Find a regression on your branch (Ask)

Good when you suspect your own diff. Switch to Agent for the fix once the explanation holds up.

[Behavior] works on main and breaks on this branch.
Using @Branch, find the change most likely to be responsible and walk me through the path from that change to the failure.
Give me one way to confirm it and the smallest fix.

Prompts for tests and refactors

13. Write failing tests first (Agent)

Step one of the test-driven flow in Cursor's own guide. Commit the tests once you're happy with them.

Write tests for [function or feature] using these input and output pairs: [pairs].
We are doing test-driven development, so do not create mock implementations for code that does not exist yet, and do not write the implementation.
Run the tests and confirm they fail for the expected reason. Then stop.

14. Make those tests pass (Agent)

Step two. Agents do well with a target they can check themselves.

Write the code that makes the tests in @[test file] pass.
Do not change the tests. Keep running them and fixing the code until they all pass.
If you think a test is wrong, stop and tell me why instead of editing it.

15. Refactor without changing behavior (Agent)

Tests go first so that you can tell a refactor from a rewrite.

Refactor @[file] to [goal, e.g. split the 600-line service into smaller modules].
Behavior must not change: keep public function names, inputs, outputs and error messages.
First list which tests cover this code and add tests for any behavior that has none.
Then refactor in small steps and run [test command] after each one.

Prompts for review and pull requests

Cursor also has built-in review tools: after Agent finishes you can run Agent Review, the /review skill picks a review agent for you, and Bugbot comments on pull requests. These two prompts work well when you want to set the criteria yourself. For a wider review checklist, see our best practices for AI in coding.

16. Review your branch like a tough reviewer (Ask)

Run it before a human sees the diff. Read-only, so it can only report.

Review @Branch as a strict reviewer.
Look for bugs, missing error handling, security problems and anything that does not match the patterns in @[example file].
Rank the findings by severity and give the file and line for each. Skip style issues our linter already catches.
If you find nothing serious, say that rather than padding the list.

17. Draft the pull request description (Ask)

Also surfaces the questions a reviewer is likely to ask, while you can still answer them.

Using @Branch, write a pull request description with: what changed, why, how to test it, the risks and where a reviewer should look first.
Use only what the diff shows, and put anything you can't tell from it in a list of questions for me.
Then list the 3 questions a reviewer is most likely to ask.

Prompts to set up rules and skills

A prompt fixes today's task. A rule or skill fixes the next hundred. Rules are instructions added to the model's context: project rules live in .cursor/rules as .mdc files, and each is set to Always Apply, Apply Intelligently, Apply to Specific Files or Apply Manually (through an @-mention). AGENTS.md is the plain-markdown alternative. Skills are SKILL.md packages in .cursor/skills that Agent loads when relevant, or that you run with /. Rule of thumb: always-true facts go in a rule, and multi-step jobs go in a skill.

18. Create a scoped project rule (Agent)

/create-rule writes the file with the right frontmatter and saves it to .cursor/rules.

/create-rule Create a project rule that applies to [glob pattern, e.g. src/api/**/*.ts].
Rules to include: [3 to 5 specific rules, e.g. validate input at the route boundary].
Point to @[canonical example file] instead of copying its code.
Leave out anything our linter already enforces.

19. Turn repeat corrections into rules (Agent)

Run it at the end of a frustrating session, while the mistakes are still in the conversation.

Look back through this conversation and list the corrections I had to give you.
For each one likely to come up again, draft a one-line project rule and say which files it should apply to.
Ignore one-off mistakes. Show me the list and wait for my approval before creating any rule.

20. Package a workflow as a skill (Agent)

For the prompt you've pasted ten times. Once saved, run it by typing / in Agent chat.

/create-skill Create a skill called [skill-name] that does this workflow:
1. [First step, e.g. look at the staged and unstaged changes]
2. [Second step, e.g. run the typecheck and tests]
3. [Last step, e.g. write a summary and open a pull request]
Write the description so it says clearly when this skill should be used. Stop and ask me if any step fails.

Common mistakes

• Tagging everything. Cursor's best practices guide warns that irrelevant files can confuse the agent about what matters.
• Patching instead of restarting. When a build misses the point, Cursor suggests reverting, sharpening the plan and running it again. That's often faster than a chain of follow-up corrections.
• Staying in one chat forever. After many turns, long conversations collect noise. Start fresh for a new task and use @Chats to bring back what you need.
• Writing a rule for everything. Skip full style guides and rare edge cases. Add a rule once you've seen the same mistake repeat.
• Saving rules as .md files. A plain .md file in .cursor/rules is ignored. Use .mdc, or AGENTS.md if you want plain markdown.
• No way to check the result. "Add tests" can end anywhere. "Cover the expired-token case in auth.ts and run the test file" has a finish line.

Choosing between editors rather than prompts? Our list of AI pair programming tools compares Cursor with its main alternatives.

Frequently Asked Questions

What makes a good Cursor prompt?
A good Cursor prompt names the job, the behavior you want, what is out of scope and how to check the result, such as a test command. Tag files when you know them. If you don't, let Agent search; Cursor's docs say it finds relevant files on its own, and that irrelevant files can confuse it.

What is the difference between Ask, Plan and Agent mode in Cursor?
Ask mode is read-only: it answers questions and explores code without edits. Plan Mode researches the codebase, asks clarifying questions and writes a plan you can edit before anything is built. Agent makes the changes, runs terminal commands and edits files. Debug Mode is a fourth option for bugs that need runtime evidence. Press Shift+Tab or use the mode picker to switch.

Where should I save Cursor prompts I reuse?
Put standing instructions in a rule (a .mdc file in .cursor/rules, or AGENTS.md) and repeatable workflows in a skill (a SKILL.md file in .cursor/skills). You can run a skill by typing / in Agent chat. Cursor's docs suggest reusing rules when you keep repeating prompts in chat.

Why is my Cursor rule being ignored?
Check the file first. Project rules must use the .mdc extension, and a plain .md file in .cursor/rules is ignored. Then check the rule type: an Apply Intelligently rule needs a description, and an Apply to Specific Files rule needs a pattern that matches files in context. Rules also don't affect Cursor Tab.

How long should a Cursor rule be?
Cursor recommends keeping rules under 500 lines, splitting large ones into smaller rules, and pointing to files instead of copying their contents. Add a rule when you notice Agent making the same mistake repeatedly.

When should I start a new Cursor conversation?
Cursor suggests starting fresh when you move to a different task, when the agent keeps making the same mistakes, or when you finish a logical unit of work. Use @Chats to pull in earlier context instead of pasting a whole conversation.