Cursor Product Mastery

An SA who fumbles the difference between Tab, Agent and Ask loses the room in the first ten minutes, because the room is full of engineers who already use one of them daily.

Cursor is not one feature with a chat box bolted on. It is three distinct interaction surfaces, each with its own latency budget, its own trust model and its own place in a developer's hands. Conflating them is the most common reason a rollout stalls: the team tries to do everything through Agent, gets burned by an over-eager edit and quietly retreats to plain autocomplete.

Your job is to make the boundaries crisp. When you can name the right surface for a given moment faster than the senior engineer in the room, you have earned the credibility to advise on the harder stuff.

Choosing the surface in a real workflowthe distinction you'll teach a hundred times

The decision is mostly about how much you already know and how much you trust the change to land unsupervised. A developer who knows the exact edit reaches for Tab. A developer who knows the goal but not the path reaches for Agent. A developer who doesn't yet understand the terrain reaches for Ask.

Demo moments that land

Toy snippets kill credibility. A scaffolded todo app proves nothing to a staff engineer who maintains a 400k-line monolith. The Agent demo that wins shows a real refactor in a repo that looks like the customer's world: extract a tangled function, thread a new parameter through five call sites, watch the agent run the test suite and self-correct on a failure.

Tab, Agent and Ask are the trio - but the surface map is much bigger nowdon't get caught describing last year's Cursor

The Tab/Agent/Ask story is correct but dated if you stop there. A year ago Cursor's core was just three things: Tab, codebase indexing and chat. It now ships constantly. The most current framing from the field team is that Cursor is an end-to-end SDLC control plane, not an editor: the same agent loop reaches across desktop, the agent window, web, mobile, the terminal, JetBrains and the cloud. An SA who still pitches "AI VS Code" is selling the 2024 product.

The other correction to make crisp: the mode dropdown changes the toolset, not the model. Picking Agent, Plan, Debug or Ask gives the same underlying model a different set of tools. New users assume "Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. = a weaker model"; it's the same model with a read-only toolset. Get this right and you'll save the room a recurring confusion.

The single biggest determinant of whether a team loves or abandons Cursor is not the model. It is the context the model receives.

Every response Agent or Ask produces is grounded in a slice of the codebase assembled at that moment. Get that slice right and the output looks like it was written by someone who knows the repo. Get it wrong and you get confident, plausible, completely off-base code. The team blames "the AI," but the failure was upstream.

How Cursor assembles context

1. 1Codebase indexing. Cursor computes embeddings of your repository so it can retrieve semantically relevant files for a given prompt, rather than relying on whatever happens to be open. This is the retrieval layer that grounds responses in your code.
2. 2Implicit context. The currently open file, the selection, recently viewed files and linter errors get pulled in automatically. Useful, but never assume it's enough for a non-trivial task.
3. 3Explicit context via @-symbols. You hand the model exactly what it needs: @files, @folders, @docs and @web. This is the lever a skilled user pulls constantly.
4. 4The context window. Everything assembled has to fit a finite budget. Stuffing in ten irrelevant files crowds out the two that mattered, so curation beats volume.

This is why context management is where most failed AI-tool rollouts actually fail. Teams expect telepathy, get confident wrong answers and conclude the tool is hype. The fix is rarely a different model. It's a workflow habit.

Coaching context as a habit

• Teach the reflex "before I prompt, what does the model need to see?" Make it the first beat of every Agent task, not an afterthought when output disappoints.
• Standardize @docs for the team's core libraries during enablement, so nobody fights a model that's guessing at an API surface.
• Show the failure on purpose: run a vague prompt, let it produce nonsense, then add two @files and rerun. The before/after is more convincing than any slide.

The mechanics behind the habits (and the numbers that sell them)what to know cold when an engineer challenges you

Senior engineers will press on how indexing works, especially on the security angle. Here's the precise mechanic: on first open Cursor chunks the repo into functions/pieces and generates vector embeddings; the embeddings are hashed and stored, but the raw code is held only ephemerally and then deleted - the only long-term store is the vector DB. At prompt time, semantic search pulls the most relevant chunks into context. The .cursorignore file lists files Cursor should never index or view, which is the control surface for sensitive code.

On @-mentions, sharpen the contrast you teach: tagging the exact file with @ guarantees that file lands in context, rather than hoping semantic search retrieves it. Asking "what color is the badge?" forces the agent to search the whole app; @badge.tsx plus "what's the hex for the badge background?" makes it read one file and return the right answer. @ isn't limited to files either - you can reference a past chat, which summarizes it and reads the transcript, so a new agent inherits the summary without carrying all prior context forward.

The SE's own superpower: your product's codebase as supercharged docsthe one habit field engineers report using all day

The highest-leverage move an SE makes with their own seat: connect Cursor to the foundational repositories of the product you sell (within your version-control access) and ask the actual codebase natural-language questions. How does this service work. How does indexing turn code into vector embeddings, and what are the embedding sizes. Was this path deprecated, is it behind a feature flag, where does it live. You're not reading docs that lag the code. You're reading the code.

That's what lets you answer the specific RFP and security questions authoritatively instead of promising a follow-up: what's the data-retention behavior, does customer data ever leave the cloud environment, is this control configurable. Keep the repo open all day, even during calls, so the answer is one prompt away.

Rules are the SA's single most impactful lever, because they turn tribal knowledge that lives in three senior engineers' heads into a standard the model follows for everyone.

Left to defaults, every developer gets slightly different output: different patterns, different libraries, different opinions on error handling. That variance is fine for one person experimenting. Across a 300-engineer org it's chaos and it's the thing a VP of Engineering worries about when they hear "we're rolling out AI coding."

Rules are how you answer that worry. They are persistent instructions that get injected into the model's context so its behavior conforms to your conventions, your stack and your guardrails.

The shape of Rules

Because Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. live in the repository, they go through pull-request review like any other change. A new convention gets proposed, debated, merged and from that moment every Agent run in the repo respects it. That is org-wide consistency without a single all-hands.

# .cursor/rules/api-conventions.md

- Use the existing `Result<T, E>` type for fallible functions; never throw across module boundaries.
- All new HTTP handlers go in `src/api/` and must register in `src/api/router.ts`.
- Database access only through the repository layer in `src/db/repos/`; no raw SQL in handlers.
- Prefer `zod` schemas for request validation; reuse schemas from `src/schemas/` when one exists.

Good rules vs. bloated rules

Why this drives expansion

Standardized Rules are how you go from one happy team to a happy org. A pilot team builds a strong rules set, it gets battle-tested and you template it for the next team's stack. New teams inherit a known-good baseline instead of rediscovering the same lessons. That repeatable pattern is exactly the land-and-expand motion an SA owns.

The four rule types and exactly when each firesthe most-asked topic in the field - know it cold

"Scope" (project vs user vs legacy) is one axis, but the axis engineers actually ask about is firing: when does a given rule get injected? There are four types, set in each rule's header. You create them via Settings > Rules, Skills, and Sub Agents > project > Rules > New, which writes an .mdc (Markdown) file under .cursor/rules with a header carrying name, description and apply setting.

Rules vs. Skills vs. Commandsthe primitive engineers most often blur

Rules are no longer the only standardization primitive, and an SA who can't draw the line loses credibility with a platform team. The clean framing: a rule is more a "what" (use Tailwind; 100% test coverage); a skill is more a "how" (here's the design system and how to apply it). Skills are an open cross-tool standard - supported across Cursor, Claude Code and Codex - that the agent auto-discovers from a name/description and invokes only when relevant (progressive disclosureHow skills load: the agent boots knowing only each skill's name and description, then pulls a skill's full instructions into context only at the moment it decides to use it.: if a skill isn't firing, the fix is usually a better description). Commands are explicit slash-triggered workflows.

Distribution scopes - the governance backbonehow a standard actually reaches the whole org

Versioned Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. answer one team's consistency; an org needs distribution. Rules, skills, commands and hooks apply at three scopes: user-level (only you), repo-level (committed, anyone with repo access) and team/org level via Teams Marketplaces - org-wide configs with sub-team variants (one set for the design team, another for backend infra). Admins can push skills, hooks and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. integrations centrally to the whole team.

MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. is the difference between an agent that knows your code and an agent that knows your company.

Model Context Protocol is an open standard for connecting Cursor to external tools, data and context sources. Instead of the agent being boxed inside the repository, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers let it reach your ticketing system, your internal docs, your observability stack and proprietary services. The protocol being open matters: it means integrations aren't a closed marketplace you wait on, they're something the customer's platform team can build for their own systems.

Enterprise use cases that move the needle

Governance when MCP touches sensitive systems

The moment an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server can read a production database or a customer-data API, security has a legitimate seat at the table. You don't wave this away. You scope it.

• Treat each MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server as a new integration point with its own access scope; least-privilege beats "give it everything and see."
• Be explicit about what data flows where, especially when a server reaches systems with regulated or customer data.
• Align MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. rollout with the same review process the customer uses for any internal tool that touches sensitive systems and bring security in early rather than retrofitting approval.
• Distinguish read-only context servers from action-taking servers; the risk profile and the approval bar differ sharply.

Scoping an MCP integration in a rollout plan

1. 1Pick a painful, bounded use case. One integration that removes real friction beats five speculative ones. "Pull the ticket into the agent" is a strong first target.
2. 2Map the data path. What does the server read, what does it write, where does that data go, who approves it.
3. 3Get security in the room early. Scope access to least-privilege and align with their existing internal-tool review.
4. 4Pilot with one team, measure, then template. Prove value on a small surface, capture the setup and reuse it as you expand to the next team.

Named integrations that move the needlestop demoing MCP conceptually - name the servers

The most common MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. demo failure is abstraction: "you can connect your tools." Be concrete. The framing that lands is MCP as the "connective tissue" layer that keeps everything inside Cursor so engineers stop swapping tools, losing flow state and burning mental bandwidth across many sources of truth. Then show a real server doing real work.

Cursor explicitly prizes the judgment to reject bad AI output and an SA who can't teach that judgment is selling autocomplete with a bigger marketing budget.

Model selection comes up in every demo and most discoveries and the honest answer is that it's a trade-off, not a leaderboard. Faster models keep you in flow and cost less per call. More capable models reason through harder, multi-step work but cost more and run slower. Auto-selection routes the task to a reasonable default so most developers don't have to think about it.

The decision tree the field team actually usesAuto first, then thinking vs non-thinking, then traits

When an engineer asks "which model should I pick?", don't hand them a leaderboard - hand them an order of operations. Auto modeA router that reads your prompt and picks a model for you, defaulting to Composer; you steer it with cues like "quickly" or "carefully". is the daily driver: a managed Cursor service that dispatches your prompt to a short list of frontier code models based on which have open capacity at the time, prioritizing runtime speed. It offboards model selection entirely. You only turn Auto off when you need a specific model's characteristics for the task in front of you.

1. 1Start with Auto. Let Cursor route the task. For most everyday work the choice doesn't matter enough to spend attention on it.
2. 2Turn Auto off only for a reason. You want a named model's specific traits - then decide thinking vs non-thinking.
3. 3Thinking vs non-thinking first. Reach for a thinking modelA reasoning model (shown with a brain icon in Cursor's picker) that spends extra compute before answering; reach for it on complex, nuanced work and a standard model for fast, simple tasks. on plans, complex environments and security/codebase scans: slower but smartest. It's overkill for simple tasks.
4. 4Then weigh traits. A frontier model like GPT-5.x can be verbose and overthink trivial tasks, but it's excellent at writing documentation and clear natural-language explanations. Match the trait to the job.

Agent autonomy vs. manual control

More autonomy is appropriate when the task has a verifiable end state and a cheap rollback: a feature branch, a test suite that will catch regressions, a diff a human approves before merge. It's risky when the blast radiusHow much breaks if a change goes wrong; the scope of potential damage. is large, the change is hard to verify or the work touches something that's expensive to get wrong. The skill is matching autonomy to reversibility.

The judgment Cursor actually hires for

Cursor bans AI in its own technical screens because it treats coding-without-AI as a clean read on whether you can evaluate code rather than just produce it. That tells you what the culture values: the engineer who reads a suggestion, spots that it's subtly wrong and rejects it is worth more than one who pastes raw output and ships. The whole product thesis assumes a human with taste stays in the loop.

Teaching trust-but-verify during enablement

• Make review non-negotiable: every Agent diff gets read before it's accepted, exactly as a human PR would.
• Normalize rejection. Show the team a wrong-but-plausible suggestion in a session and reject it out loud, so they learn rejection is the skill, not a failure of the tool.
• Connect model behavior to outcomes they care about: faster drafts only help if review load stays sane and incident risk doesn't creep up.

A great demo is a spine, not a script: plan first, let the model surface a discrepancy, verify in the browser and hand back proof. The four beats below survive an unexpected codebase and let you narrate judgment at every step.

The single biggest workshop recommendation across Cursor's own field sessions is the same one that makes a demo land: start in Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes.. It's the antidote to the "agent went rogue across six files" story, and it's where you can show thinking out loud before any code is written.

1. 1Beat 1 - Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes.. Switch to Plan mode and give the goal. It makes no edits: it researches the whole indexed codebase, follows existing paradigms and outputs a hyperlinked Markdown plan (scope, implementation, tests, concrete to-dos, often a data-flow diagram). Editing the plan costs zero tokens, so you converse or edit the Markdown directly - and teammates can sign off before execution.
2. 2Beat 2 - Surface a discrepancy. Let Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. ask its clarifying questions instead of rushing past them. This is the moment that wins skeptics.
3. 3Beat 3 - Execute, then verify in the browser. Switch to Agent to run the to-dos, then open the built-in browser, give a plain-language directive and watch the change render while Cursor surgically edits only the necessary files.
4. 4Beat 4 - Hand back proof. Show artifacts: the agent self-tests, records a video and screenshots and can upload the walkthrough straight to the PR.

Two opening moves before the spinehow field engineers set up a demo that fits the prospect

The four beats assume you already have a repo that looks like the customer's world. Field engineers don't keep a shelf of pre-baked templates. They build the environment live. Open a brand-new Cursor window on a totally blank editor, then prompt the agent to populate a repo tailored to the prospect's exact scenario - a COBOL codebase to refactor, a service that mirrors their stack. Describe the environment, why it's set up that way and the workflow it should facilitate, and you get a runnable repo in minutes instead of hand-wiring dependencies for days. Pre-baked demos become fully bespoke demos, built per call.

The second opening move proves comprehension of a complex or legacy codebase, which is the exact fear in a modernization conversation. After a high-level analysis, prompt the agent: "build me an architecture diagram written in Mermaid and saved to a Markdown file." The agent broadly scans the repo and produces a visual asset. Preview it in Cursor's Markdown preview with ⌘+⇧+V and you get a clean visual breakdown that proves Cursor actually understands the dependencies. The same ⌘+⇧+V trick renders any generated demo narrative or plan nicely.

Tie the spine back to the role: the demo isn't proving Cursor types fast. It's proving the workflow you'll coach - plan, interrogate, verify, prove - which is exactly the trust-but-verify discipline that makes a rollout safe.