Good Cursor prompts tell the agent which mode to work in, which files matter, what must not change and how to check the result. Below are 14 original prompts for Cursor's Agent, Ask, Plan and Debug modes and for code you select in the editor, grouped by job: understand, plan, change, debug, review, and set up rules and skills.
How to use these prompts
Copy a prompt into the Cursor chat and replace the blanks in double braces, or keep the default after the colon: {{test_command:npm test}} means npm test unless you change it. Anything that starts with @ is a Cursor @ mention: type @ and pick the file, folder, terminal or diff so the real content is attached.
A few Cursor features these prompts rely on, all from the official docs:
| Feature | What it does | How to reach it |
|---|---|---|
| Agent | Edits files, runs terminal commands, searches the codebase | Side pane, Cmd+I (Ctrl+I) |
| Ask mode | Read-only answers about your code, no edits | Shift+Tab or the mode picker |
| Plan Mode | Asks questions, researches, writes an editable plan before code | Shift+Tab or the mode picker |
| Debug Mode | Forms hypotheses, adds logs, asks you to reproduce, then fixes | Shift+Tab or the mode picker |
| Selected code | Sends highlighted lines to Agent | Select, then Cmd+K or Cmd+L |
| Checkpoints | Snapshots of your code during an Agent session, so you can roll back | Restore Checkpoint on an earlier message |
Two habits make every prompt here work better. First, state the boundary: which files the agent may touch and what must stay as it is. Second, end with a check the agent can run itself, like a test command or a type check, so it knows when it is done. Switching modes starts a fresh context window, and Cursor's help center suggests a new chat when you change tasks.
Understand the code
1. Map an unfamiliar codebase (Ask mode)
Switch to Ask mode first. It is read-only, so the agent explores without editing anything.
I'm new to this repo. Without changing any files, give me a map of it:
1. What the app does, in two sentences.
2. The main folders and what lives in each.
3. How a request flows from {{entry_point:the HTTP router}} to the database.
4. Where config, environment variables and secrets are read.
5. The three files I should read first to understand {{area:billing}}.
Cite file paths for every claim. If something is unclear, say so instead
of guessing.
2. Explain selected code
Select the lines, press Cmd+L or Cmd+K to send them to Agent, then paste this. Useful for dense functions, regexes and old code nobody remembers writing.
Explain the selected code to a developer who knows {{language:TypeScript}}
but not this project.
- What it does in one sentence.
- Step by step, what happens to the input.
- Every caller of this code in the repo, with file paths.
- Anything fragile: hidden assumptions, missing error handling, edge
cases that would break it.
Do not change any code.
Plan before building
3. Plan a feature (Plan Mode)
Plan Mode researches the codebase and writes a plan you can edit before any code is written. Give it the goal and the constraints, then review the plan before clicking build.
Plan this feature: {{feature:let users export their invoices as CSV}}.
Context:
- Who uses it: {{users:account admins}}
- Must work with:
{{constraints:the existing permissions system and the current invoices API}}
- Out of scope: {{out_of_scope:PDF export, scheduled exports}}
Before you plan, ask me any questions that would change the design.
The plan should list: files to add or change, data or API changes, the
order of steps, how each step will be tested, and the risks. Keep each
step small enough to review on its own.
4. Scoped task with hard limits
For a change you already understand. The file list and the "do not touch" list keep the agent from wandering.
Task: {{task:add a "last login" column to the users admin table}}.
You may edit only:
{{allowed_files:@src/admin/users/ and @src/api/users.ts}}
Do not change:
{{protected:the database schema, auth code, shared UI components}}. If the
task needs changes there, stop and tell me why.
When you're done, run {{test_command:npm test}} and
{{typecheck:npm run typecheck}}, fix anything you broke, and summarize
what changed in a short list.
Change code
5. Rewrite selected code in place
This replaces the old inline edit habit. Select the code, press Cmd+K, and keep the instruction narrow.
Rewrite only the selected code to
{{goal:remove the nested ifs and make the early returns obvious}}.
Keep the function signature, return values and thrown errors exactly the
same. Don't touch code outside the selection. If a test covers this
function, run it after the change.
6. Write tests for selected code
Select a function, send it to Agent, and point at an existing test file so the new tests match your style.
Write tests for the selected code using {{framework:Vitest}}.
Match the style of {{example_test:@src/lib/__tests__/format.test.ts}}.
Cover the normal case, edge cases
({{edge_cases:empty input, null, very large numbers}}) and every error path.
One behavior per test, with a name that says what it checks.
Put the tests in {{test_location:the matching __tests__ folder}}, run
them, and show me the result. If a test fails because of a real bug,
don't fix the code: tell me what you found.
7. Multi-file refactor in safe steps
Large refactors go wrong in the middle. Small steps with a test run after each give you clean checkpoints to restore if a step goes sideways.
Refactor {{target:the data fetching in @src/features/orders/}} to
{{goal:use the shared apiClient instead of raw fetch calls}}.
Rules:
- Do not change behavior or any public export.
- Work in small steps. After each step, run {{test_command:npm test}}
and stop if anything fails.
- Before you start, list the steps you plan to take and the files each
one touches.
- At the end, list anything you chose not to change and why.
8. Build UI from a screenshot
Cursor accepts pasted or dragged images in the chat. Attach the mockup, then name the components you already have so the agent reuses them.
Build the screen in the attached image as
{{component:a new SettingsPage component}} in {{location:@src/app/settings/}}.
Use our existing components from {{ui_folder:@src/components/ui/}}
instead of writing new ones. Use our spacing and color tokens, not
hard-coded values. Match the layout and hierarchy; exact pixel values
matter less than consistency with the rest of the app.
List anything in the image you couldn't map to an existing component.
Debug
9. Hard bug report (Debug Mode)
Debug Mode adds logging, asks you to reproduce the bug, and fixes from the evidence. It works best with precise expected and actual behavior.
Bug: {{bug:the cart total is sometimes wrong after removing an item}}
Steps to reproduce:
{{steps}}
Expected: {{expected}}
Actual: {{actual}}
How often: {{frequency:about 1 in 5 tries, more on slow networks}}
Started after: {{started:unknown}}
Don't fix anything until the logs confirm the cause. Tell me which
hypothesis the evidence supports, then make the smallest fix and remove
the instrumentation.
10. Fix a failing test from the terminal
Run the failing tests first, then attach the output with @Terminals.
The tests in @Terminals are failing.
For each failure: say whether the test or the code is wrong, with the
evidence. Fix the code if the code is wrong. Only change a test if it
checks behavior we no longer want, and tell me when you do.
Do not skip, delete or loosen any test to make it pass. Rerun
{{test_command:npm test}} until it's green, then list each fix in one
line.
Review and ship
11. Review your branch before a PR
@Branch (Diff with Main) attaches the full branch diff. Cursor also has a built-in Agent Review you can run with /agent-review; this prompt is for when you want a review with your own priorities.
Review @Branch (Diff with Main) as a strict senior reviewer.
Focus on, in order: bugs and wrong logic, security problems
({{security_focus:auth checks, injection, secrets in code}}), missing
error handling, missing tests, then readability.
For each finding give: file and line, severity (blocker, should fix,
nit), what's wrong, and the fix. Don't edit any files. Skip style
issues our linter already catches.
12. Commit message and PR description
@Commit (Diff of Working State) attaches your uncommitted changes.
Read @Commit (Diff of Working State) and write:
1. A commit message: summary line under 72 characters in the imperative
mood, a blank line, then why the change was made.
{{convention:Use plain messages, not Conventional Commits.}}
2. A PR description with: what changed, why, how to test it step by
step, and anything reviewers should look at closely.
Describe only what is in the diff. Don't run git commands.
Set up rules and skills
13. Turn your conventions into a project rule
Project rules live in .cursor/rules as .mdc files, and their frontmatter decides when they load: always, for matching files, when the agent judges them relevant, or when you @ mention them. Cursor also ships a built-in /create-rule skill; this prompt gives it real material to work from. See the Cursor rules guide for rule types and frontmatter.
Look through this codebase and draft a project rule for
{{scope:our React components}}.
Base it on patterns you can actually see in the code: file naming,
folder structure, state management, styling, error handling, testing.
Include three to six short do and don't lines, each with a file path
that shows the pattern.
Save it as .cursor/rules/{{rule_name:react-components}}.mdc with
frontmatter that applies it to {{globs:src/components/**/*.tsx}}.
Don't invent conventions the code doesn't follow.
14. Turn a repeated prompt into a skill
If you paste the same workflow every week, make it a skill so you can call it with /. The Cursor skills guide covers folders and frontmatter.
Create an Agent Skill called {{skill_name:release-notes}} that
{{job:writes release notes from the commits since the last tag}}.
Write a SKILL.md with a name and a description that says when to use
it. In the body, give numbered steps, the exact output format, and two
or three rules about what to leave out. Keep it short enough to read in
a minute. Save it as .cursor/skills/{{skill_name:release-notes}}/SKILL.md
and tell me how to call it.
What makes a Cursor prompt work?
Most weak prompts fail in the same three ways: no boundary, no check, and too much at once. Cursor's own prompting docs suggest @ mentions when you know which files matter, and letting the agent search when you don't. Pick the mode before you type: Ask when you only want answers, Plan when the change is big or unclear, Debug when you've already failed to fix a bug once, and Agent for everything else.
When the agent takes a wrong turn, don't argue with it in a long thread. Restore a checkpoint, tighten the prompt, and run it again. Checkpoints are stored locally and separately from Git, so commit the work you want to keep.
For prompts that work in any tool, see the coding prompts and debugging prompts collections. If you also build in browser app builders, the Lovable prompts and v0 prompts pages follow the same approach.
Keep your best prompts one keystroke away
Prompts like these are worth keeping. Kipt stores them as Markdown in a private GitHub repo you own: save a prompt with its {{blanks}}, tag it, and find it again with Cmd+K. When a prompt becomes a workflow you run often, the free SKILL.md generator turns it into a valid SKILL.md in your browser, ready for Cursor, Claude Code or Codex.