Master Prompting for Cursor: Anchor Your App Extensions with Precision

A good Cursor prompt does not ask the agent to “make the app better.” It gives the agent enough of your codebase’s context to make one change without inventing a second design system. The reliable pattern has four anchors: conventions, an existing example, a tight scope, and a definition of done.

Without those anchors, a vague request such as “add a settings page” leaves important decisions unstated. The agent must guess the component shape, file locations, state management, validation behavior, and stopping point. The result may compile while still being wrong for your repository.

Cursor’s Agent documentation describes an agent that can search files, read and edit code, run terminal commands, use a browser, and create checkpoints. Those capabilities make a precise prompt more important, not less. The agent can touch a large surface quickly; your prompt should define the surface it is allowed to touch.

Anchor one: conventions

Start by pointing the agent to the project rules that explain how the repository works. Cursor’s Rules documentation describes project rules stored in .cursor/rules and version-controlled with the code. It also documents AGENTS.md as a Markdown alternative.

A useful rule file contains decisions that should survive from one session to the next:

# Project conventions

- Read the closest existing feature before editing.
- Reuse existing components and validation helpers.
- Keep authorization at the server data boundary.
- Do not add a dependency without explaining the need.
- Do not edit generated files by hand.
- Run the focused test and type check before reporting completion.
- Report assumptions and checks that were not run.

Cursor’s documentation notes that project rules use .mdc files with metadata such as description, globs, and alwaysApply. A plain .md file inside .cursor/rules is ignored by that rules system; use the documented format or put simple Markdown instructions in AGENTS.md.

Keep conventions concrete. “Write clean code” gives the agent no useful decision. “Server actions return { data, error } and do not throw across the action boundary” gives it a pattern to follow and a reviewer a clear rule to check.

Anchor two: an existing example

The fastest way to make generated code look like your code is to point at a nearby feature that already solves a similar problem. Models are better at extending a demonstrated pattern than inventing one from a sentence.

Find an example with the same kind of:

• Component state.
• Data access.
• Validation.
• Loading and error behavior.
• Permission boundary.
• Test fixture.

Then name the file and explain what should carry over:

Example: use the layout and error-state pattern from
src/features/billing/BillingNotificationRow.tsx.
Keep its spacing, control placement, naming style, and test structure.
Read that file before proposing edits.

Read the example yourself first. If you cannot find a suitable reference, that is useful information: the missing example may be the first small task to create. Do not pretend a generic component from training data is a repository convention.

One good example is usually better than ten paragraphs describing an abstract style. It gives the agent real imports, real names, and real neighboring behavior to inspect.

Anchor three: scope

Turn a feature into a bounded change. Name the files, symbols, and things that must remain unchanged. “Add account deletion” may involve a route, a confirmation dialog, a server action, an audit event, a job, an email, and a settings link. “Add the confirmation state to this existing dialog” is a smaller first slice.

Scope:
- Add one server action in src/features/account/actions.ts.
- Edit the existing account dialog only to call that action.
- Reuse the current session and audit helpers.
- Do not change routing, billing, email templates, or database schema.
- If a required behavior needs another file, stop and list it first.

A scoped prompt makes review possible. It also prevents a common failure mode: the agent solves the visible request by rewriting adjacent code it was never asked to touch.

Ask for a plan before implementation when the feature crosses a data boundary:

Plan only. Inspect the account dialog, session helper, and audit helper.
Return the files you would change, the authorization checks required,
and the tests you would add. Do not edit yet.

Review the plan against the repository. Correct a wrong assumption before it becomes a multi-file diff.

Anchor four: definition of done

Tell the agent exactly what completion means. “Make it work” usually means “the code compiles.” Your definition should include behavior, boundaries, tests, and a stopping condition.

DONE: the existing dialog confirms the action, calls the current server
boundary, shows the existing success and error states, rejects an expired
session, passes the focused tests, and changes no unrelated files.

A good done statement is observable. It gives you a checklist for the diff and tells the agent when to stop. Add a size or file boundary when that matters, but do not optimize for an arbitrary line count at the expense of a correct design.

Use a four-anchor prompt

Here is the complete pattern for a small settings change:

Add a DarkModeToggle row to the existing settings page.

CONVENTIONS
Read the repository rules first. Reuse the existing theme provider and
shared row components. Do not add a dependency or a second provider.

EXAMPLE
Match the structure of
src/components/settings/NotificationRow.tsx: same label spacing, control
placement, token usage, and test style. Read it before editing.

SCOPE
- Add the toggle component in src/components/settings/DarkModeToggle.tsx.
- Insert one row in src/features/settings/SettingsPage.tsx.
- Use the existing theme provider for persistence.
- Do not change routing or unrelated settings.

DONE
The row appears between Notifications and Account, changes the theme,
uses the existing tokens, passes the focused test, and reports any check
that could not run.

Notice what this prompt does not include. It does not prescribe a new state library, invent a route, rewrite navigation, or ask for a complete visual redesign. The repository supplies the implementation details; the prompt supplies the boundary.

Match the interaction to the task

Cursor’s Agent documentation lists file search, file reading, editing, terminal execution, browser control, and checkpoints among Agent capabilities. Use the smallest interaction that fits the work.

Ask a question when you need an explanation or file map. Use a local edit for a small, selected change. Use Agent for a bounded multi-file task where it can inspect the repository, edit files, and run checks.

Do not give an agent a large task merely because it can execute many tool calls. A clear five-file change is easier to review than a vague request to rebuild a feature area.

Iterate on the diff

The first output is a draft. Review the diff, then ask for targeted corrections instead of requesting a full rewrite.

Review the current diff and make only these corrections:
1. Replace the direct color with the existing surface token.
2. Remove the new provider; use the repository theme provider.
3. Add the missing denial-path test.
Do not modify any other files.

This keeps correct work intact and limits the next turn’s search space. If the agent starts editing outside scope, stop it and ask for an explanation before continuing.

Use checkpoints for recovery during exploration, but use Git for durable history and review. Cursor documents checkpoints as local snapshots that let you preview and restore file changes; they do not replace commits or a pull request.

Define verification in the prompt

Include the checks you expect before the agent starts:

Verification:
- Run the focused settings test.
- Run the type check for the changed package.
- Inspect the complete diff.
- Report passed, failed, and not-run checks separately.

For a permissioned feature, require a negative test. For a form, require validation and server-error states. For a cross-platform component, require the relevant web and native checks. A green build alone does not prove that the feature follows the repository’s behavior.

Treat “not run” as a useful result. If a dependency, simulator, or external service is unavailable, record that limitation rather than turning it into an implied pass.

Give the agent durable context

The four anchors work best when your repository already contains the context they reference. Keep conventions near the code, name stable examples, and add tests for mistakes that recur. A project rule should capture a decision; a prompt should describe the current change.

OTF’s templates page verifies a free MIT component SDK and a free AI configurations pack for Cursor, Claude, and Lovable. That is the relevant OTF connection: reusable components and project context can reduce setup work, but they do not replace your application’s tests, authorization, or review.

For the wider release gate, read AI coding agent acceptance checklist. For repository structure that helps an agent find the right files, read agent-readable repository structure.

The practical rule is simple: show the agent how your code works, point it to one example, name the files it may touch, and define the evidence required to finish. Better prompts are not longer for their own sake. They are specific where a guess would create rework.

Sources

• Cursor Agent documentation
• Cursor rules documentation
• OTF templates