Cursor prompts: 16 copyable prompts for Agent, Plan Mode and chat

01 Plan a feature without writing code

A Plan Mode prompt that makes the agent read the code, ask questions and return a one-page plan you can edit.

Mode

Plan Mode (Shift+Tab).

Attach

The two or three files closest to the feature.

Hard part

Answering its questions honestly instead of saying "you decide".

Per Cursor's docs, Plan Mode asks clarifying questions, researches the codebase and produces a plan you can edit before building. The prompt below tells it what the plan must contain, so you get something reviewable instead of an essay.

Plan this change. Do not write code yet.

Goal: [one sentence]
Context: @[file or folder] @[file or folder]

First read the code that this touches, then ask me up to five questions.

The plan must contain:
1. Files to change and files to create
2. Steps in order, each small enough to review alone
3. What could break, and how I would notice
4. How I verify each step (command or behavior)

Keep it to one page.

If the build drifts from the plan, don't patch it. Revert, make the plan more specific, and run it again.

02 Map an unfamiliar codebase

A read-only prompt that explains how a part of a project works, with file names, before you change anything.

Mode

Chat or Agent, read-only.

Attach

A folder, or nothing and let search find it.

Hard part

Asking about one flow, not "the whole repo".

Cursor describes a built-in Explore subagent that searches and analyzes codebases using a faster model. A narrow question gives it something to find. Ask about one flow, such as sign-in, checkout or the build step.

Do not edit any files. Explain how [flow, for example user sign-in] works in this project.

Give me:
1. The entry point and every file the flow passes through, in order, with file paths
2. Where data is read and where it is written
3. Anything surprising, fragile or duplicated
4. Three questions I should ask before changing it

If you are unsure about a step, say so instead of guessing.

03 Compare two approaches before choosing

A chat prompt that makes the agent argue both options against your actual code, so the decision rests on your constraints.

Mode

Plan Mode or chat.

Attach

The module where the choice lands.

Hard part

Stating your real constraints, such as team size and deadline.

I need to decide between two approaches for [problem].

Option A: [short description]
Option B: [short description]
Context: @[file or folder]

My constraints: [team size, deadline, things I cannot change]

For each option give: the files it changes, the main risk, how hard it is to undo, and what it costs me later. Then recommend one and say what would change your mind. No code.

Keep the answer. Paste the winning option into your Plan Mode prompt from the first entry, and write the reason down in a rules file so nobody reopens the debate.

01 Reproduce the bug, then fix it

An Agent prompt that writes a failing test first, so you know the fix works and the bug stays dead.

Mode

Agent.

Attach

The file where it breaks and the terminal with the error.

Hard part

A bug report specific enough to reproduce.

Bug: [what happens]
Expected: [what should happen]
Steps: [how to trigger it]
Context: @[file] @Terminals

Do this in order:
1. Write a test that fails because of this bug. Run it and show me it fails.
2. Make the smallest change that makes it pass.
3. Run the full test suite and the linter.

Do not refactor, rename or upgrade anything else. If you cannot reproduce the bug, stop and tell me what you tried.

Attaching terminal output with @Terminals saves you copying a stack trace by hand. The docs list it as a context type.

02 Fix the error in my terminal

A short prompt that turns a failing command into a diagnosis and a fix, using the output Cursor can already see.

Mode

Agent.

Attach

@Terminals.

Hard part

Telling it which command you ran and what changed since it last worked.

"What changed since it worked" is the most useful sentence you can add. One board idea, which env var changed between the deploy that worked and the one that didn't, exists because that question is so common.

@Terminals

This command fails: [command]
It worked [yesterday / before I changed X].

1. Read the error and tell me the most likely cause in two sentences.
2. List what you checked to reach that conclusion.
3. Fix it with the smallest change.
4. Re-run the command and show me the result.

If the cause is a missing environment variable or secret, tell me its name. Do not invent a value.

Read “Fix the error in my terminal” on the board and copy its build prompt →

03 Turn a screenshot into a component

A prompt that uses image input to build one UI component that matches a mockup, then checks it in the browser.

Mode

Agent, with the image pasted in.

Attach

The screenshot, plus your component folder.

Hard part

Asking for one component, not a whole page.

Cursor's docs say you can drag an image into the prompt or paste it with Cmd+V, including screenshots, and that vision-capable models can use it. The agent also has a Browser tool that can take screenshots to verify visual changes.

[paste image]

Build the card shown in the image as one component, using the components and styles in @[components folder]. Match spacing, type size and colors as closely as you can.

Limits: no new dependencies, no changes to existing components, use the design tokens already in the project.

Done when: the component renders on [route or story], and you have opened it in the browser and compared it with the image. Tell me every difference you see.

04 Refactor without changing behavior

A prompt for restructuring code that pins the behavior with tests before moving a single line.

Mode

Plan Mode first, then Agent.

Attach

The file to refactor and its tests.

Hard part

Code with no tests, where the first step is to write some.

Refactor @[file] to [goal, for example split into three modules by responsibility].

Rules:
1. If the current behavior has no tests, write tests that capture it first and run them.
2. Change structure only. No behavior changes, no renamed public functions, no new dependencies.
3. After each step run the tests. Stop if any fail and tell me which.
4. At the end, list every file you changed and one sentence on why.

If you find a bug while refactoring, do not fix it. Note it at the end.

Agent creates checkpoints before significant changes, so a wrong turn is a restore away. They are separate from Git, so commit when the tests pass.

05 Upgrade a dependency and repair what breaks

A bounded upgrade prompt that reads the changelog, makes the bump and fixes only what the upgrade broke.

Mode

Agent, or a Cloud Agent for a big upgrade.

Attach

Your package manifest.

Hard part

Major versions with breaking changes in code you did not write.

Upgrade [package] from [old version] to [new version] in @package.json.

1. Search the web for the official migration notes and list the breaking changes that affect this project.
2. Make the upgrade.
3. Run the type check, linter and tests.
4. Fix only what the upgrade broke, one fix at a time, re-running the checks after each.

Do not upgrade any other package. If a fix needs a design decision, stop and ask me.

01 Write tests for a file that has none

A prompt that writes tests for behavior you describe, not just the lines that exist, and names the edge cases.

Mode

Agent.

Attach

The file, and one existing test file as a style example.

Hard part

Tests that only mirror the implementation.

Write tests for @[file]. Use the same test framework and style as @[existing test file].

Test the behavior, not the implementation. Cover:
- the normal case
- empty, null and zero inputs
- the boundary values
- at least two ways the function should fail, and how

Run the tests. Then break the code on purpose in one place and confirm a test fails. Undo the break.

Do not change the source file.

The last step matters. A test that cannot fail proves nothing, and asking the agent to break the code and watch a test fail is the quickest check you can ask for.

02 Review my branch before I open the pull request

A self-review prompt using @Branch, adapted from the approach in Cursor's own docs.

Mode

Chat or Agent, read-only.

Attach

@Branch (Diff with Main).

Hard part

Telling it what standard to review against.

Cursor's docs suggest tagging @Branch to give the agent the full diff of your current branch, then asking it to review the changes. There is also a dedicated Agent Review in the Source Control tab. A prompt lets you set the standard.

@Branch (Diff with Main)

Review this branch as a careful colleague would before merge. Do not edit files.

Look for, in this order:
1. Bugs and missed edge cases
2. Missing error handling
3. Changes that do not match the patterns in @[a file that shows our conventions]
4. Anything that could be a security problem

For each finding give: file and line, why it matters, and a suggested fix. Then list questions a reviewer will ask. Say "no issues found" for a category only if you checked it.

03 Security pass on a change

A focused prompt that checks a diff for the mistakes AI-written code makes most: secrets in client code, missing checks on the server.

Mode

Chat, read-only.

Attach

@Commit (Diff of Working State) or @Branch.

Hard part

It cannot replace a human review for payments or personal data.

@Commit (Diff of Working State)

Check this change for security problems only:
1. Any secret, key or token in code that ships to the browser
2. Any server route that does not check who is calling it
3. Any database query built from user input by string concatenation
4. Any place user input is shown on a page without escaping
5. New dependencies, and whether each is needed

For each issue: file, line, risk in one sentence, fix. Do not edit files. If you find nothing in a category, say what you looked at.

For code that handles payments, sign-in or personal data, treat this as a first filter and get an experienced person to review it.

04 Verify a UI change in the browser

A prompt that makes the agent open the app, click through the flow and report what it saw, using Cursor's Browser tool.

Mode

Agent.

Attach

@Browser, if the app is already open.

Hard part

The dev server has to be running, and the flow has to be clear.

The docs describe a Browser tool that can navigate, interact with elements and capture state for analysis. The prompt supplies the flow to test.

Start the dev server if it is not running. Open the app in the browser and test this flow:

1. [step]
2. [step]
3. [step]

At each step take a screenshot and tell me what you see. Report anything that looks broken, misaligned or slow. Do not change any code. If a step fails, stop and describe exactly where.

01 Rework messy commits into reviewable ones

A prompt, taken from the approach in Cursor's docs, that turns one large change into small commits with clear messages.

Mode

Agent.

Attach

Nothing; it reads the git state.

Hard part

Do it on a branch so you can compare.

Cursor's docs recommend small, semantic commits, and describe an agent resetting to main, reading all the changes, planning a logical order and checking that the final diff matches the original. They suggest turning that into a skill you can run after finishing a feature.

Rework the commits on this branch into small, reviewable commits.

1. Create a backup branch of the current state first.
2. Read the whole diff against main and propose a sequence of commits, each one logical change. Show me the sequence and wait for my approval.
3. Create the commits with clear messages: a short summary line, then a sentence on why.
4. Check that the final diff matches the backup branch exactly. If not, say what differs.

Do not push.

02 Write the pull request description from the diff

A prompt that drafts a description a reviewer can use: what changed, why, how to test it and what to look at first.

Mode

Chat.

Attach

@Branch (Diff with Main).

Hard part

It knows what changed but not why. Tell it the reason.

The same source diff can feed a changelog. A board idea about a changelog your users actually read is a good example of a tool built from this kind of input.

@Branch (Diff with Main)

Write a pull request description. The reason for this change: [one or two sentences].

Sections: Summary (3 bullets), Why, How to test (numbered steps a reviewer can follow), Risks, and What to review first.
Write in plain language. Do not describe every file. Do not claim anything you did not see in the diff.

Read “Write the pull request description from the diff” on the board and copy its build prompt →

03 Write the rules file for this project

A prompt that reads the codebase and drafts the conventions file so future prompts stay short.

Mode

Agent.

Attach

Your config files and a couple of representative source files.

Hard part

Editing the draft down to what is true and necessary.

Cursor reads rules and AGENTS.md files, and its Cloud Agents docs recommend a dedicated section for cloud setup instructions. A first draft from the agent is a starting point, not the final file. The Cursor rules guide explains where each type lives.

Read @package.json, the config files in the repo root and three representative source files. Draft an AGENTS.md for this project.

Include only what you can see in the code: how to install, run, test and lint; the folder layout; naming and style conventions that are actually used; and things the code avoids.
Mark anything you are guessing with [CHECK]. Keep it under 60 lines. Do not invent commands.

04 Hand a well-defined task to a Cloud Agent

A delegation prompt for a cloud machine: self-contained, with a pass or fail check and a pull request as the output.

Mode

Cloud Agent (Premium or above).

Attach

Nothing local; the agent clones the repository.

Hard part

No one is there to answer questions, so the brief must be complete.

A cloud agent works on its own branch in its own virtual machine and can test what it builds. A small tool like explain this cron expression in plain English, and the reverse, a board idea, suits it because the answers are checkable. See the Cursor agent guide for setup.

Build [small tool] and open a pull request.

What it does: [one paragraph]
Inputs and outputs, with examples:
- Input: [example] -> Output: [expected]
- Input: [example] -> Output: [expected]
- Input: [bad example] -> Output: a clear error message

Rules:
- Follow the conventions in AGENTS.md.
- Write tests for every example above and make them pass.
- No new dependencies unless you explain why in the pull request.
- Put the test output in the pull request description.

If the task is ambiguous, make the simplest reasonable choice and list your assumptions in the pull request.

Read “Hand a well-defined task to a Cloud Agent” on the board and copy its build prompt →