Skip to content

Cursor: Intermediate

Intermediate

You’ve run the Agent and accepted some Tab suggestions. The jump from “occasionally useful” to “real workflow” is almost entirely about context: what the Agent can see, and what standing instructions it follows. Cursor gives you precise control over both.

In the Agent chat, type @ to attach specific context instead of hoping Cursor guesses right. The Agent also retrieves relevant code automatically from its index of your codebase, but @ lets you be exact.

SymbolBrings in
@file / @folderA specific file or directory
@codeA named function, class, or symbol
@docsIndexed external/framework documentation
@webA live web search
@git / @diffCommits or your current diff
@terminalRecent terminal output
@linter errorsCurrent linter problems, as a readable check

Choosing what to attach (and what to leave out) is the whole game. Everything you add competes for room in the context window, so attach what’s load-bearing and skip the rest.

Give Cursor standing instructions: .cursor/rules

Section titled “Give Cursor standing instructions: .cursor/rules”

Re-typing your conventions in every chat doesn’t scale. Project Rules are committed instruction files the Agent reads automatically. They live as .mdc files in .cursor/rules/, version-controlled so the whole team gets identical behaviour.

Each .mdc file has YAML frontmatter with three fields:

---
description: API conventions for this repo
globs: src/api/**
alwaysApply: false
---
Validate every request body with zod. Return typed error objects, never throw raw strings.

How a rule activates depends on those fields:

ActivationHow it triggers
Always ApplyalwaysApply: true, included on every request
Apply IntelligentlyThe model decides from the description
Apply to Specific Filesglobs match files already in context
Apply ManuallyYou call it with @rule-name

For repo-wide guidance without frontmatter, you can also drop an AGENTS.md at the project root (or in nested subdirectories). And User Rules in Settings hold your personal preferences across all projects, but note they apply only to Agent/Chat, not to Inline Edit (Cmd/Ctrl + K).

This is context engineering in practice: rules are the steering, the model is the engine. The model has no opinion about your conventions until you write them down.

The Agent surfaces every change as a reviewable diff, and the native browser tool (shipped with Cursor 2.0) lets it test its own output and iterate. Use that loop deliberately:

  1. Give the Agent a small, well-scoped task with the right @ context attached.

  2. Read the diff. Run the tests or let the Agent run them; feed @linter errors back if anything breaks.

  3. If it’s drifting after a correction or two, don’t keep patching inline. Revert to a checkpoint and rewrite the prompt with what you learned.

The failure mode to avoid is the kitchen-sink chat: one endless thread where you correct the Agent ten times. Each correction pollutes the context. Reverting and restarting with a sharper prompt almost always beats fighting the same thread.

  • ✅ You attach precise context with @file, @docs, and @web instead of relying on auto-retrieval alone
  • ✅ You have at least one .cursor/rules/*.mdc committed and watched the Agent obey it
  • ✅ When a chat drifts, you revert and refine the prompt rather than correcting in place

Ready for Plan and Ask modes, MCP tools, Memories, and picking the right model?