Cursor core features: pick the right tool and verify the result

Cursor’s core features are the tools a developer uses every day in the editor: Tab completions, inline edit, the agent with its modes, terminal commands, @ context, checkpoints, and Bugbot pull request review. Each one covers a different size of change, and each one saves time only when a type, lint or test gate checks what it produced.

This page is for developers who have finished the essential Cursor configuration and still use Cursor like a plain editor with a chat pane. You type a 20-line change by hand because opening the agent feels heavy. Then you hand the agent a feature that needed a plan, get a 14-file diff back, and spend the afternoon reading it. The fix is to match each change to the right feature and to decide up front how you will check the result.

The Cursor 3.x line, checked on 26 September 2026. Plan Mode, Bugbot and Rules were verified against Cursor’s docs on 28 August 2026; Bugbot’s trigger comment and BUGBOT.md come from a secondary source. The agent’s codebase search, grep, web search, web fetch, lint reading, and image input were confirmed in the agent runtime shipped in Cursor’s @cursor/sdk 1.0.32 package (the version on npm on 26 September 2026; later patch releases exist). Cursor’s keyboard shortcuts could not be verified for 3.x on that date, and the available sources disagree about them. This page therefore names each feature by what it does: to find one, open the command palette (Cmd+Shift+P on macOS, Ctrl+Shift+P on Windows and Linux), search for the feature by name, and the palette shows the binding your build uses.

What you’ll walk away with from Cursor’s core features

A decision table that maps the size of a change to Tab, inline edit, Agent or Plan Mode, together with the check that ends each one.
Seven copy-paste prompts: a scoped inline edit, a fix-until-green loop, a pre-PR gate, a code search that cites its sources, a plan, a screenshot-driven UI fix and a commit message.
A scope check and a gate run that tell you whether to keep an agent turn without reading every line of it.
A commit-per-green-turn habit that turns checkpoints into a second safety net rather than the only one.
Recovery steps for the six ways these features most often go wrong.

Which Cursor feature fits the change?

Pick the feature by how much of the change you can already describe, not by habit. The smaller the tool, the cheaper the check.

The change	Feature	What it may touch	How you check it	Deep dive
The next few lines, and the pattern is visible nearby	Tab	The lines around the cursor	Type checker and watch-mode tests as you go	Tab autocomplete
One function or block you can select, described in one sentence	Inline edit	The selection	Tests for that function, plus a diff limited to the selection	Inline edit
Several files, and you can name the files and the command that proves it works	Agent	Files and terminal commands, within your run mode	Scope check, then the gate command	Agent chat workflows
Several files, and you could not write the acceptance criteria right now	Plan Mode, then Agent	Nothing until you approve the plan	A plan that lists every file and one test per criterion	Agent modes
A finished branch, before a human reviewer sees it	Bugbot	Comments on the pull request	Findings you fix or dismiss, then CI	Bugbot

Edit code in place with Tab, inline edit and the agent

Three features change code in the editor, from a few lines to many files. Start with the smallest one that fits the change.

How do you use Cursor Tab for multi-line edits?

Cursor Tab predicts an edit near the cursor, which can span several lines, and it can offer a jump to the next place that needs a related change. Press Tab to accept and Esc to dismiss. After a rename or a new field, keep pressing Tab through the chain, but read each step: a chain of ten accepted edits is ten decisions.

Tab copies the pattern it sees. If a suggestion ignores your conventions, open the closest existing example near the cursor or make the first change by hand, then let Tab continue it. Keep the type checker and tests running in watch mode, so a wrong suggestion fails within seconds of the accept. Tab autocomplete covers partial accepts and seeding.

How do you use Cursor inline edit on a selection?

To open inline edit, select the code and search the command palette for “inline edit”; the palette shows the default binding in your build. Inline edit rewrites the selected code from a one-sentence instruction, or generates code at the cursor when nothing is selected. It is faster than the agent because it changes only the selection, and that same limit makes the result easy to check.

Inline edit sees the selection and the file around it. It does not open the helper you import from another file. When the edit depends on a pattern elsewhere, name that pattern in the instruction or use the agent instead.

Wrap this function body in error handling. Catch only errors from the fetch call and
the JSON parse. Log them with the existing logger from src/lib/logger.ts, including
the function name and the order ID, then rethrow an AppError with a message a user
could act on. Do not change the function signature or the return type.

After you accept, run the tests for that module. If the diff reaches outside the selection, reject it and select a smaller block.

When do you open Cursor’s agent, and in which mode?

The agent panel is where multi-file work happens. Open it from the command palette (search for “agent”), which also shows its binding in your build. If you select code before you open it, the selection comes along as context. The agent can read and edit files, search the codebase and run terminal commands, subject to your run mode.

Choose a mode in the chat input’s mode picker before you send the prompt:

Agent edits files and runs commands. Use it when you can name the files and the command that proves the change.
Plan Mode “creates detailed implementation plans before writing any code” (Cursor’s Plan Mode page, verified 28 August 2026). Use it when you cannot yet write the acceptance criteria.
Your picker may list other modes as well (not verified on 26 September 2026). For a read-only answer, use Plan Mode and add “do not edit files” to the prompt; for a runtime bug, see bug hunting in Cursor.

Agent modes in Cursor has the full decision table and the signals for switching mid-task.

Hand terminal work to Cursor’s agent

The terminal is where the agent proves its own work: it runs the checks, reads the errors and tries again. Keep the stop condition a command’s exit code.

How do you draft a terminal command from a description in Cursor?

Cursor’s inline edit also works in the integrated terminal in builds that offer it; with the terminal focused, the command palette shows whether yours does and which key opens it. Describe the command, and Cursor drafts it for you to review before it runs. For example, “show the last 20 commits as a graph with branch names” drafts a git log command with the right flags.

Read a drafted command before you press Enter, especially anything with rm, --force, reset or a redirect into a file. The draft does not know your aliases or which package manager the project uses. Put that in a project rule, as project rules in Cursor shows, for example “use pnpm, never npm”.

How do you make Cursor’s agent fix errors until the build is green?

The agent can run a check, read the errors, fix them and run the check again. This is where it pays for itself, provided the stop condition is a command’s exit code and not the agent’s opinion.

Run `npx tsc --noEmit` and fix every error it reports. After each round of fixes,
run it again. Stop when it exits with code 0, or after five rounds, whichever comes
first. Rules: do not change exported function signatures, do not add `any`,
`@ts-ignore` or `@ts-expect-error`, and do not edit files under tests/.
Finish with the list of files you changed and the final command output.

The same shape works for cargo check, go vet ./... or pytest. The rules line matters most: without it, the fastest way to a green build is to silence the checker. Whether the agent runs these commands without asking depends on your run mode; keep type, lint and test commands allowed, and keep anything that pushes or deletes behind approval.

Save the prompt below as docs/prompts/pre-pr.md, commit it, and attach it with @ before you open a pull request. Everyone on the team then runs the same gate in the same order.

Run these commands in order and fix what fails before moving to the next one:
1. pnpm run typecheck
2. pnpm run lint
3. pnpm run test

Do not modify or delete test assertions, snapshots or lint configuration to make a
step pass; fix the source code instead. If a test looks wrong, stop and tell me why.
When all three pass, report: each command with its exit code, the files you changed,
and anything you were unsure about.

The report is the point. You check three exit codes and a file list instead of rereading the diff. If your team wants the same gate to run automatically when the agent stops, the essential configuration page sets it up as a stop hook.

Find code and give Cursor’s agent the right context

The agent’s answer is only as good as what it reads. These four habits get the right files in front of it, and in front of you.

How do you ask Cursor’s agent where code lives?

Cursor’s agent has a semantic codebase search tool as well as grep and glob (confirmed in @cursor/sdk 1.0.32; see the note at the top of this page). Describe what you want in plain language, and it finds code by meaning: a question about “authentication” can land on a function named issueToken. Ask it to cite what it found, so you can check the answer in seconds.

Where does this codebase create and validate JWT tokens for signed-in users?
Search by meaning first, then confirm with an exact-text search. For each place,
give the file path, the function name and one line of code that proves it.
List anything related you found but are not sure about separately. Do not edit files.

How do you attach context with `@` in Cursor?

Type @ in the agent input to attach files, folders, code, documentation or earlier chats; the picker on your screen shows what your build offers. One canonical example file beats a paragraph of description: “Create POST /api/orders following @src/routes/users.ts” gives the agent a pattern to copy. After pasting a prompt, check that every @ reference turned into an attached item rather than plain text.

For current library docs or your branch’s changes, ask in plain language. The agent has web search, web fetch and a terminal, so “search the web for the tRPC v11 router syntax” or “review the changes on my branch against main” works without a special mention. Context management in Cursor covers folder mentions, .cursorignore and handing off between chats.

How do you jump to a symbol by name in Cursor?

Cursor inherits VS Code’s default navigation bindings unless your build rebinds them (not verified for 3.x on 26 September 2026; the command palette shows the binding in yours). Cmd+Shift+O (Ctrl+Shift+O) lists the symbols in the current file, and Cmd+T (Ctrl+T) searches symbols across the workspace. Run the workspace search with focus in the editor; the chat input may bind the same key differently.

How do you open a file at a given line in Cursor?

In VS Code’s default bindings, which Cursor inherits unless your build rebinds them, Cmd+P (Ctrl+P) opens Quick Open with fuzzy file matching. Add a colon and a line number to land on a line: auth.ts:42. This is the fastest way to follow a file path the agent gives you in its report.

Undo agent turns and ship changes from Cursor

Git is the restore point you can trust; checkpoints and Bugbot are extra layers on top of it.

How do you undo an agent turn in Cursor safely?

Cursor keeps checkpoints of the agent’s changes that you can restore from the chat. Before you rely on one, run the short scope test on Checkpoints and branching to confirm what a restore touches in your build. Plan on a checkpoint restoring files at most: it cannot undo a migration, a package install or a push, and it is not a commit. Build the habit around Git instead:

Run git status --short before each agent task. If it prints anything, commit or stash it, so the agent’s changes are the only changes.
Give the agent a scope (the directories it may touch) and the gate command.
When the turn ends, run the scope check below and the gate.
If both pass, commit: git add -A && git commit -m "agent: <what changed>". If either fails, restore the checkpoint or discard files with git restore, then re-prompt with the reason.

This scope check runs in the terminal at the repository root and prints every changed or new file outside the paths you allowed. Replace the two paths with your own:

{ git diff --name-only HEAD; git ls-files --others --exclude-standard; } \
  | grep -v -E '^(src/auth/|tests/auth/)' || echo "scope OK"

If the check prints a path, the turn went outside its scope: restore it or discard that file before you commit.

How do you draft a commit message from the staged diff in Cursor?

The agent can write the commit message from a prompt, and you can tell it your team’s format. Stage one coherent change at a time: a focused diff produces a focused message.

Run `git diff --staged` and write a Conventional Commits message for those changes
only: a type and scope, a summary under 72 characters in the imperative mood, and a
body that explains why the change was made. The reason is: customers were charged
twice when the payment webhook retried. Do not mention files that are not staged.
Show me the message; do not commit.

A diff shows what changed but not why, so give the reason in one sentence. Enforce the format with commitlint in a commit-msg hook or in CI rather than by rereading messages; Cursor time savers shows the setup.

How do you let Bugbot take the first review pass?

Bugbot is Cursor’s pull request reviewer: it “reviews pull requests and identifies bugs, security issues, and code quality problems” (Cursor’s Bugbot page, verified 28 August 2026). Once it is enabled for a repository, it comments on each pull request. Per Cursor’s help pages (a secondary source, not re-checked on 26 September 2026), commenting bugbot run on a pull request re-runs a review, and a committed .cursor/BUGBOT.md gives Bugbot project guidance.

Treat Bugbot as one layer, not the gate. Its findings still need a decision, and CI still has to pass. Bugbot: learned rules and Autofix covers the rules file, Autofix and a seeded-defect test that proves Bugbot catches real bugs. Pricing is left out here on purpose; check Cursor’s pricing page.

Plan features and show Cursor’s agent what you see

The two cheapest ways to avoid a wrong diff are a reviewed plan and a picture of the target.

How do you plan a feature in Cursor’s Plan Mode before building it?

For a feature that spans layers, start in Plan Mode. The agent researches the codebase and writes a plan before any edit; the prompt below makes it ask its open questions first. A plan is much cheaper to review than a diff.

I need in-app notifications when an order ships. Read @src/lib/ and @src/api/ to
understand the current architecture, then write a plan that:
1. Lists every file you will create or change, and why.
2. Describes the data flow from the shipping event to the UI.
3. Recommends server-sent events or WebSockets for this codebase, with the reason.
4. States each acceptance criterion and the test that will prove it.
5. Names anything with side effects outside the code: migrations, new packages, config.
Ask me your open questions first. Do not edit any file until I reply "approved".

Answer the questions, trim the steps you do not want, then build the approved plan in Agent mode. The file list becomes the scope for the scope check in the section on undoing an agent turn.

How do you fix UI from a screenshot with Cursor’s agent?

The agent accepts images in the chat: drag in a screenshot, a mockup or a design export. Pair it with a project rule that names your design tokens and components, so the agent maps the picture onto your system instead of writing one-off CSS. Screenshots of bugs work too.

The attached screenshot is the order summary page at 375px wide. The "Pay now" button
overlaps the price card. Fix it using the breakpoints and spacing tokens already
defined in src/styles/tokens.css; do not add new breakpoints or hard-coded pixel
values. Change only files under src/components/checkout/. Then tell me which
component and which CSS rule caused the overlap.

Check the fix at the same width in the browser, and add a visual or component test if the project has them. Frontend UI in Cursor goes further.

How do you check the output without reading every line?

Every section above ends in evidence rather than trust. The checks, in the order to run them:

Check	What it catches	Who signs off
Scope check (undoing an agent turn)	Files changed outside what you asked for	You, before the commit
Gate command with exit codes (fix-until-green loop, pre-PR gate)	Type errors, lint failures, broken tests	The command; you read three exit codes
Tests written from acceptance criteria (Plan Mode)	Code that compiles but does the wrong thing	You approve the criteria; the tests hold them
Bugbot findings	Bugs and security issues a gate cannot see	The pull request author, then the human reviewer
CI on the pull request	Everything above, on a clean machine	Your branch protection rules

Read the code where the checks are thin: security-sensitive paths, data migrations and anything the tests do not exercise. The evidence bundle is the cross-tool version of this table for pull requests.

When Cursor’s core features misfire

Inline edit writes code that does not compile. The edit depended on a type or helper outside the selection. Undo it, then either widen the selection to include what it needs or switch to the agent and attach the file with @.

A drafted terminal command uses the wrong tool. The draft suggested npm in a pnpm project, or a macOS flag on Linux. Reject it, then add the project’s package manager and platform to a project rule so later drafts follow it.

The agent turned the build green by weakening the checks. Look for new any (including as any and <any> casts), @ts-ignore, eslint-disable and skipped tests with this command, which leaves the index untouched:

{ git diff -U0 HEAD; git ls-files --others --exclude-standard -z \
    | xargs -0 -I{} git diff -U0 --no-index /dev/null {}; } \
  | grep -E '^\+.*(ts-ignore|ts-expect-error|eslint-disable|\.skip\(|: any\b|as any\b|<any>)'

Only lines that start with + count: removing an old @ts-ignore is not a regression. The first part diffs tracked files against HEAD, including changes the agent already staged; the second diffs each new untracked file against an empty file. Then list any checker config it touched with git diff --name-only HEAD -- '*eslint*' '*tsconfig*' '*.oxlintrc*'. Restore the checkpoint, and add the rule “do not silence the checker” to the prompt, as in the fix-until-green prompt above.

The agent edited files you did not mention. The scope check prints them. Discard each one with git restore --source=HEAD -- <path> or delete new files, then re-prompt with the allowed directories and “stop and ask if you need a file outside this scope”.

A checkpoint restore left the project in a mixed state. Files the agent created, or commands it ran, may survive a restore. Run git status --short and remove what does not belong. If the agent ran a migration or installed a package, reverse that by hand; then commit before the next turn so Git holds a clean restore point.

Bugbot keeps flagging an intentional pattern. Explain in .cursor/BUGBOT.md why the pattern is intentional, and dismiss the current comment. If a finding is real, fix it before the human review, not after.

Where to go next after Cursor’s core features

Cursor Tab: multi-line edits you can verify goes deeper on Tab, the first feature above.
Agent chat workflows in Cursor takes the agent from request to a proven change.
Checkpoints and branching makes every agent turn disposable.
Keyboard shortcuts lists the rest of the bindings.
Working in the terminal instead of the IDE? The same habits for Claude Code are in Claude Code efficiency hacks, and for Codex in Codex efficiency hacks.