Cursor: an editor built around context
Lesson 5 of 12
5Cursor: an editor built around context
Same model, different results. Not because it is “smarter” but because of what it can see, this part is about managing context, and about one rules file that changes the assistant's answer entirely.
What the picture shows: Open files and the rules file go into the context window with your question, and the answer changes with what the model saw.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
Two people get the same question: you give the first one page, and the second the whole file plus the team's rules. The second answers better, not because they are smarter, but because they see more. Cursor is an editor built around that idea: choosing exactly what the assistant sees.
Answer quality follows context: files referenced with @, the repository index, and the .cursor/rules file that adds standing instructions to every request. Too much unrelated context hurts as much as too little, so add only what the question needs.
Required fundamentals
Part four
You saw an agent write files, and saw its test that cannot fail. This part explains why it wrote it that way.
A project with more than one file
The mini-agent-demo folder from the previous part is enough. The idea does not show up on a single file.
A working VS Code
Cursor is a modified build of it, so everything will look familiar, and it offers to import your settings on first launch.
Willingness to swap one idea for another
You will drop “which assistant is smarter?” and pick up “which assistant sees more?”. The second question is the right one.
Core concepts
An editor built on VS Code itself (a fork), so your keybindings, extensions and theme come with you. The difference is not the editor; it is that the AI sits at its centre rather than being bolted on.
Context is the product. Every assistant uses comparable models; the difference is how much, and how precisely, is loaded into the context window before it answers. An assistant that sees your project beats a smarter one that sees a single file.
The editor builds an index of the project so it can answer “where is this function used?” without you opening files. That also means your code is read and sent, so know your organisation's policy before indexing a private repository.
A text file in your project that is read with every request: your style, your prohibitions, your definition of the word “test”. Rules live in AGENTS.md, or in .mdc files inside a .cursor/rules folder.
@ loads one named file, folder or symbol. An explicit mention is always more precise than automatic indexing, and the real skill is knowing what to attach, not attaching everything.
A separate editor, a subscription, and dependence on one vendor. Plans and feature names change often, check the official site; the transferable skill is context management, not the name of a button.
How it works
Diagram 1, Every answer is built from this mixture alone, whatever did not enter the window does not exist to the model
Diagram 2, The ladder of sight and permission: each rung sees more, does more, and needs more review
And these are the mention forms you will type most:
@dice.js one file @mini-agent-demo/ a whole folder @AGENTS.md the rules, pinned explicitly #roll a symbol, wherever it is defined @web the live internet, not the training data
The exercise: one rules file that fixes the previous part's bug
In part four we asked for a “test” and got a file that prints and checks nothing. The agent was not wrong by standards we never gave it: the word “test” is ambiguous, and it picked the simplest reading. The fix is not a better prompt, it is a rule written once.
# Project rules for mini-agent-demo ## Testing - A test MUST assert. A file that only calls `console.log` is not a test. - Every test MUST exit non-zero when a check fails. - Cover: the happy path, the boundaries, and at least one invalid input. - Name real tests `*.spec.js`. Never name a print-only script `*.test.js`. ## Style - CommonJS (`require` / `module.exports`), no build step. - Validate arguments at the top of a function and throw a typed error. - No new dependencies without asking first. ## Before you say you are done - Run `node dice.spec.js` and paste the real output. - Break the implementation once, re-run, and confirm the test goes red.
Drop that file at the project root and the folder becomes:
mini-agent-demo/ ├── AGENTS.md <- standing instructions, read every time ├── dice.js ├── dice.spec.js <- the real test (asserts, can fail) ├── dice.test.js <- the print-only script from part 4 └── README.md
console.log is not a test” is precisely the mistake the agent made in the previous part.dice.js and run the test. If it does not go red, the rule was not applied and the model is not the problem.| Without a rules file | With a rules file | |
|---|---|---|
| Definition of “test” | The model's guess | Your own sentence |
| Consistent across sessions | No | Yes |
| Travels to the team | No | Yes, with the repository |
| Needs re-explaining each time | Yes | No |
| Review still required of you | All of it | All of it, a rule reduces error, not responsibility |
Myth vs. reality
| The myth | The reality |
|---|---|
| “Cursor is smarter because its answers are better.” | It usually runs the same models. What changes is the context loaded before the answer, and that is yours to control. |
| “Attach the whole project so it understands more.” | The window is finite. Over-attaching crowds out what matters and makes the answer broader, not sharper. |
| “A rules file is needless bureaucracy.” | It is the difference between an assistant guessing your standards and one that knows them. It is the cheapest document in the project. |
| “I need to learn Cursor specifically.” | The transferable skills are context management, writing rules, and review. Tools change; those do not. |
| “Indexing is an internal detail, not my concern.” | Indexing means your code is sent for processing. On a private project that is a policy decision, not a technical footnote. |
Try it yourself
You want to change a function in dice.js that is called from three files. What is best to attach?
Attach what will change, what defines the correct contract, and what defines your style. The first floods the window, the second forgets the callers, and the fourth assumes indexing is enough, it is less precise than an explicit mention.
Which line works as a rule in AGENTS.md?
Because it is the only checkable one: you can run the test and read the exit code. The rest are wishes nobody, model or human, can prove they followed.
Quick review flashcards
AGENTS.md at the root, or .mdc files inside .cursor/rules.@ do?Check your understanding
1. In one sentence: why does the same model answer better inside an AI-first editor?
Because it is answering a different question. The first is “complete this line”; the second is “complete this line while seeing the related files, the rules and the test”. The intelligence is constant; the evidence changed.
2. Why does over-attaching hurt?
Because the context window is finite and competitive: every unnecessary file takes space the important one needed, and pushes the model toward broader generalities. Precision comes from selection, not volume.
3. (Spot the bug) A colleague wrote a 120-line rules file and results did not improve. What is likely?
The rules are not checkable (“clean code”, “high performance”), or they contradict each other, or they are long enough to consume the context the code needed. The cure: cut them to ten sentences whose compliance can be demonstrated.
4. Your manager asks: do we buy subscriptions for the whole team? What do you need to know first?
Three things: the company's policy on sending code out for processing (indexing), whether the codebase is large enough that project-wide understanding actually helps, and whether the team reviews diffs. Without review you are buying speed at producing code nobody understands.
5. (Decision) You have got much faster, and you notice you no longer know how half your project works. What do you do?
Treat that as a warning, not an achievement. The cure is practical: write the first version of anything new yourself, use the assistant for repetition and explanation rather than decisions, and hold yourself to being able to explain every file you merge in one sentence. Speed that outruns your understanding is debt, not output.
Resources for this part
Sorted by kind: start with the official docs when you want the precise reference, or with an article or video when you want the explanation first.