How to Prompt Cursor for Coding (2026): Formulas + Examples

Prompting Cursor well is not about phrasing — it's about pointing it at the right context and defining what "done" means. Cursor can edit across your repo, run commands, and run your tests, but it only acts on what you feed it. Hand it the exact files, the mode that fits the job, a specific task with real paths, and a clear finish line, and you get a correct change. Leave any of those vague and you get a plausible-looking guess.

That's why technique beats model choice here. A precise prompt with the right context will out-code a sloppy one on any model. This guide gives you a repeatable formula, then eight worked example prompts you can paste into the Cursor chat pane. For a ready-made set, browse the best Cursor prompts, keep the Cursor prompt cheat sheet open, and see the Cursor Agent mode prompts for autonomous work.

The formula

A good Cursor prompt has four parts, in this order: Context → Mode → Task → Constraints & Acceptance. Fill each one and the model has everything it needs to act instead of guess.

Context comes first because it's the biggest lever. Use @-symbols (@Files, @Folders, @Code, @Codebase) and # to pull the exact code, docs, and errors into the prompt. Don't make Cursor go hunting — point at what matters.

Mode is your intent. Ask is read-only: use it to understand or plan. Agent makes the change: it edits files, runs commands, runs tests, and iterates. Pick the one that matches what you actually want to happen.

Task is the specific thing to do, with exact paths. "Add a rate limiter to @middleware/rate-limit.ts" beats "add rate limiting" every time.

Constraints & Acceptance close the loop: scope what to touch ("only edit these files, don't change unrelated code"), tell it to run the tests, ask it to show the plan or diff, and state how you'll know it worked ("done when the login test passes"). Here's the skeleton:

[Context] Look at @Files [path] and @Code [symbol]. Reference @Docs [library] if needed.

[Task] [Exactly what to build or change, naming the real files it lives in.]

[Constraints]
- Only touch [these files]; don't change unrelated code.
- Follow the patterns already in the files above.
- Add or update tests, then run them.

[Acceptance] Done when: [tests pass / this behavior is true]. Show me the plan before editing and the diff when you're finished.

Why it works: every part removes one thing Cursor would otherwise have to assume, and assumptions are where wrong edits come from.

Point at context with @-symbols

@-symbols are how you hand Cursor context explicitly instead of hoping semantic search finds it. This is the single highest-leverage habit in Cursor prompting. Reach for the narrowest symbol that covers what the model needs.

Combine them. Give Cursor the file to change, the symbol to match, and the docs for the API, and it has no reason to invent anything:

Using @Files [src/api/client.ts] as the pattern to match and @Docs [library-name] for the API, add a new method to @Code [ApiClient] that [does X].

Keep the same error-handling and retry style as the existing methods in that file. Don't change any other file.

Best for: new code that has to fit an existing pattern — the sibling file plus the docs is usually all the context Cursor needs.

Ask vs Agent (and Plan)

Pick the mode by what you want to happen. Ask is read-only — it answers questions and plans but won't edit files, so it's safe for exploring unfamiliar code. Agent is autonomous — it plans, edits across files, runs terminal commands and tests, reads the output, and iterates until the task is done. For anything non-trivial, have Agent propose a plan first (via the Plan step) so you approve the approach before it writes a line.

Start big tasks in Ask or ask for a plan, then switch to Agent to execute:

Ask mode — don't edit anything yet.

I want to [add feature / change behavior]. Look at @Folders [relevant/dir] and @Codebase to find the files involved.

Give me a short plan: which files you'd change, in what order, what could break, and what tests you'd add. I'll review it, then have you implement in Agent mode.

Why it works: a plan you approve up front is far cheaper to correct than a sprawling multi-file edit you have to unwind afterward.

Be specific & scope it

Vague prompts are the main reason Cursor "does the wrong thing." The fix is to name exact paths, scope what it may touch, and state acceptance criteria. Compare a throwaway prompt with a precise one:

Bad: Add auth.

Good — Agent mode.

Add email + password login. Context: use the existing session helper in @Files [lib/session.ts] and wire the route into @Files [routes/auth.ts]. Match the validation style in @Code [validateSignup].

Scope: only edit lib/session.ts, routes/auth.ts, and the auth test file. Don't touch the user model or any UI.

Add tests for a valid login, a wrong password, and an unknown email, then run them.

Done when: the three new auth tests pass and existing tests still pass. Show me the plan first, then the per-file diff.

Why it works: the good version leaves one reasonable interpretation. Exact paths, an explicit scope fence, and a testable finish line turn "add auth" from a coin flip into a target Cursor can hit.

The same discipline applies to changes, not just new features — name the file, the current behavior, and the desired behavior:

Agent mode. In @Files [utils/date.ts], the formatDate function currently [current behavior]. Change it so it [desired behavior], keeping the same signature.

Only edit utils/date.ts and its test file. Update the tests to cover the new behavior and the edge cases [list them], then run the test suite.

Done when: all date tests pass. Show the diff.

Best for: targeted edits — pinning the exact function and file stops Agent from wandering into unrelated code.

Encode standards in .cursor/rules

Anything you'd repeat in every prompt belongs in rules — persistent instructions Cursor injects into every Ask, Agent, and inline run. Modern Cursor (2026) uses a .cursor/rules/ directory of .mdc files, each scoped by glob and metadata. The rule types are Always (injected everywhere), Auto Attached (when a matching glob is in context), Agent Requested (the model pulls it in when relevant), and Manual (only when you @-mention it). The legacy single .cursorrules file at the repo root still works. You can also run /Generate Cursor Rules to draft a rule from a chat.

Keep rules short and specific — they cost tokens on every run. Here's a compact example .mdc file you could drop in .cursor/rules/backend.mdc:

---
description: Backend conventions for the API service
globs: src/api/**/*.ts
alwaysApply: false
---

- Stack: [framework + version]. Use [ORM/library]; do not add new deps without asking.
- Every route handler validates input with [validation lib] and returns typed errors.
- Business logic lives in src/services; handlers stay thin.
- Write tests in [test framework] next to the code; run them before finishing.
- Never log secrets or PII. Never touch files outside src/api for a backend task.

Why it works: the glob scopes the rule to backend files, so Cursor auto-attaches these standards whenever you work in src/api — no need to restate them in every prompt.

Make it verify itself

The last part of the formula is the highest-value one: make Cursor prove the change works instead of trusting it. State acceptance criteria, tell Agent to write tests and run them, then review the per-file diff before accepting and iterate on anything wrong. Bundle verification into the task itself:

Agent mode. Implement [change] in @Files [path].

Before you finish:
- Write tests covering [the happy path + these edge cases].
- Run the full test suite and fix anything that fails.
- Run @Lint Errors and clear any you introduced.

Done when: all tests pass and there are no new lint errors. Report what you changed, then show me the diff grouped by file. Don't mark it done until the tests actually run green.

Why it works: "don't mark it done until the tests run green" forces Agent to close the loop itself, so you're reviewing a verified change, not a hopeful one.

When something is still off after a run, iterate by feeding the failure straight back in — the terminal output is context, so point at it:

That didn't fully work. Look at @Terminal for the failing test output and @Git for the diff you just made.

Find the root cause, fix it with the smallest change, and re-run the tests to confirm. Don't rewrite the parts that already pass — only touch what's needed to make the failing test green. Show me the updated diff.

Best for: tightening a near-miss — handing Cursor the real failure output beats describing it, and the "smallest change" constraint stops it from thrashing. Once you've internalized this formula, the best Cursor prompts and the cheat sheet become fill-in-the-blank templates.