Cursor features: a practical guide for developers

You open a repository and need to change something. Perhaps the next edit is obvious. Perhaps you need to follow a request through five files before you understand the bug. Cursor has tools for both situations, but they need different kinds of input.

This guide follows a small web project from an unfamiliar codebase to a checked change. You will see where Tab, Agent, planning, Rules, Skills, MCP, and background work fit, with prompts you can adapt. The later articles turn one recurring task—checking documentation against code—into a reusable procedure and then an Automation.

You do not need to configure every feature before starting. You need a repository you can inspect, one task with a recognizable outcome, and a way to verify the result.

Understand what each tool is for

Think about the scope of the task before choosing. Finishing a mapping function is a small edit. Diagnosing a stale search result requires investigation. Checking the same documentation every week is recurring work. The fact that all three involve code does not make them the same request.

The product links in this series were checked on October 2, 2026. The worked examples are teaching examples, so replace their paths and assumptions with those in your own project.

Start by learning the repository

Before asking for a change, establish where the behavior lives. An agent can make a plausible edit in the wrong layer if the request never explains which layer owns the behavior.

Suppose the project contains a search box, an API client, and a results renderer. Start with this request:

Explain how search works in this repository before making changes.

Find:
- The input event handler.
- The function that sends the search request.
- The code that renders results, loading, and error states.
- Tests covering those paths, if present.

Follow one query from typing to rendering. Cite the actual file paths
and relevant functions. Separate what you verified in code from anything
you inferred. Do not edit files or install dependencies.

The requested output is a map you can verify. Open the files it cites. Does the handler really call that API client? Does the renderer handle errors, or did the explanation assume it does? Resolving those questions now is cheaper than reviewing a patch built on the wrong assumption.

Provide a short task-specific starting point if you know one: “The issue occurs on the product search page” or “The handler is probably in src/search.js.” Avoid pasting the entire repository into the prompt. Give the agent enough direction to find the relevant files, then check what it actually found.

Use Tab when the next edit is already clear

Tab suggests edits based on nearby code and recent changes. It can handle multiple lines and related files. Accept with Tab or reject with Escape. Cursor Tab guide

For example, imagine that you are mapping API data into a product card:

function toProductCard(product) {
  return {
    id: product.id,
    title: product.name,
    price: product.price,
  };
}

You decide to add a fallback title and start editing the title line. A suggestion might use product.name || 'Untitled'. Whether that is correct depends on the data contract. Should an empty string count as missing? Should a whitespace-only name be trimmed? Does the API permit null?

Tab is useful because it keeps you in the editing flow. You still supply the decision about behavior. If you do not know the contract, investigate it before accepting a convenient fallback.

For a well-understood repetitive change, review the coordinated edits too. Adding a property to the mapper may require updating a test fixture or a consumer. An accepted suggestion in one file does not establish that all uses are consistent.

Give Agent a problem and a finish line

Agent can search, edit, and run commands. Cursor also provides browser tools and checkpoints; checkpoints help restore local file changes, while Git remains the durable version history. Agent documentation

A useful task prompt identifies the behavior that is wrong, the behavior you want, and the constraints around the change. Compare “fix search” with this:

Fix stale results on the product search page.

Problem:
When someone types "ca" and then "cat", the request for "ca" can finish
last and replace the newer results.

Investigate:
Locate the input handler and request/rendering code. Explain the race
and identify the smallest place to prevent it.

Expected behavior:
- Only the latest query may update results, loading, or error state.
- Clearing the input also prevents older responses from appearing.
- A failed latest request shows the existing error UI.
- A failed older request does not replace the current state.

Constraints:
Keep the existing API client and visual design. Do not add a dependency
unless the current implementation cannot support the fix; explain first.

Verification:
Use the project's existing test tools. Exercise reversed response order,
clearing the input, and a rejected request. If a browser check is possible,
try the search flow there too. Report exactly what ran.

Return the cause, changed files, test results, and remaining limitations.
Keep the changes local for review.

The first two lines tell the agent what to investigate. The acceptance criteria prevent a partial fix: guarding the results but leaving an old error handler active would still be wrong. The constraints limit unrelated changes, and the report format gives you a practical review checklist.

A good response should connect the patch to those criteria. “Added a request counter” is an implementation description. “An earlier request can no longer update results or clear loading after a newer request starts” describes the behavior you can test.

Plan larger changes before editing

A stale-response fix may be small enough to investigate and patch in one task. Moving search state into a shared module could affect several pages, tests, and lifecycle assumptions. That is a better point to use Plan Mode.

Ask for a plan with decisions you can evaluate:

Plan a shared search controller for the catalog and order pages.
Do not implement it yet.

Inspect the current handlers and identify duplicated behavior.
Propose the smallest shared interface for request, result, loading,
error, and disposal behavior. Preserve each page's existing UI.

List the files you expect to change, tests to add or update, and any
assumption that needs my answer. Explain whether a shared controller
actually reduces complexity compared with keeping the handlers separate.

Read the proposed interface before the file list. If the abstraction makes simple pages harder to understand, change the plan. A detailed plan can still be a poor design.

Also check the disposal story. When a page is removed, pending work should not keep updating it. Asking about lifecycle early is more useful than adding cleanup after the refactor is complete.

Put recurring constraints in Rules

Some instructions belong to the repository rather than a single bug report. Examples include using the existing API client, reading a design contract before changing UI, or avoiding generated output directories.

Cursor supports project rules under .cursor/rules; it also recognizes AGENTS.md as a simpler Markdown instruction surface. Rules documentation

Start with a constraint that has a concrete effect:

Before changing UI, read DESIGN.md.
Use existing color tokens and controls.
For async UI work, explain how stale results and disposal are handled.
Report build checks separately from browser behavior checks.

“Write excellent code” does not tell the agent how to choose between two implementations. A path to the design guide and a lifecycle requirement do.

Keep the detailed explanation in the guide. If you copy the full design guide into a rule, you now have two documents to update whenever the design changes. Part two shows complete rule files and how to scope them.

Use Skills for work you repeat

A Skill packages a task procedure. For example, a documentation check needs to locate the guides, compare their claims with source, classify mismatches, and return evidence. That procedure should not have to be reconstructed from an old chat each time. Skills documentation

The difference matters when you write instructions. “Keep the current stack” is a persistent constraint. “Compare README commands with package.json, then report mismatches” is a task. You can combine them: the rule preserves project conventions while the skill runs the check.

A skill is also a useful place to define the no-finding result. Without that instruction, an agent may fill a report with general suggestions simply because it was asked to review something. A clear procedure can say that an empty result is acceptable and require evidence for every finding.

We will build that documentation skill in the next article, including a small fixture that makes correct and incorrect reports easy to distinguish.

Add MCP when the answer lives outside the repository

MCP connects Cursor to external tools and data sources. MCP documentation

Consider a bug report stored in an issue tracker. The repository contains the handler, but the ticket contains the steps to reproduce it. An integration can make that context available without manually copying each update into chat.

Define the task before connecting tools:

Read the linked issue and extract its reproduction steps and expected
behavior. Then trace those steps through the current repository.
Do not change the issue or post a comment. If access is unavailable,
state what information is missing rather than inventing the ticket content.

Reading a ticket and posting a reply are separate capabilities. Configure the access the task needs. A prompt describes intended behavior, but the actual tools determine which actions are available.

For an integration you have not used before, begin with a small retrieval task and inspect the returned source. Verify that it refers to the intended project, account, and record before building a larger workflow around it.

Move repeated work into the background

Cloud Agents run remotely; their environment needs the repository and tools required by the task. Automations supply the event or schedule that starts a run. Cloud environment setup and Automations

For a documentation check, the inputs might be the current branch, README.md, package.json, and source paths. The output is a report. For a PR review, the inputs also include the diff, commit history, and earlier review findings. Those extra inputs explain why the PR workflow needs more design than simply adding a push trigger.

Before scheduling anything, answer three questions: what should start it, what should a successful run produce, and what should happen when an input is unavailable? A workflow that silently reviews the wrong branch is worse than one that stops with a clear setup error.

Bugbot is Cursor's managed review option. A custom reviewer lets you define your own review policy and output, but also leaves you responsible for testing that behavior. The fourth article develops that tradeoff without assuming a custom workflow is cheaper.

Review the evidence and keep the useful instructions

After an agent finishes, inspect the diff and its verification report together. Look for changes outside the requested scope, missing failure paths, and assertions that are stronger than the evidence. A passing build supports a build claim; it does not prove that two overlapping requests render in the right order.

When the same mistake recurs, decide where its correction belongs. A one-off constraint belongs in the task. A repository convention belongs in a rule. A repeated sequence of work belongs in a skill. A recurring trigger belongs in an Automation.

Start by giving one real task a clear finish line. Then create the Rules and Skills that make that context reusable.

Cursor series

1. Cursor features: a practical guide for developers — you are here
2. Cursor Rules and Skills: give your project clear instructions
3. How to create a custom Cursor Automation
4. Build a custom PR reviewer with Cursor Automations