Cursor quick start: from install to a verified first feature

The Cursor quick start is ten short guides, about two hours in total, that take a developer from a fresh install to a first feature proved by evidence. It sets up a verify command, a run mode, project rules, and MCP, then builds a feature in Plan Mode where tests, not a line-by-line read, decide when it is done.

It is for the developer setting up Cursor on a real repository and the tech lead who commits the result for the team. In a first session the agent often edits several files, says it is done, and only your checks can tell you whether it is.

What the Cursor quick start gives you

A verify script (type check, lint, tests) that the agent, a hook, and CI all call.
A run mode that runs that script unprompted and keeps git push behind approval, plus .cursorignore so the agent cannot read secrets.
Project rules in git that every teammate’s agent follows.
One feature merged with evidence: criteria, a test per criterion, a green gate, a scoped diff.

In what order should you set up Cursor?

Do steps 1–8 in order; take 9 and 10 when you need them.

#	Guide	Time	Done when
1	Install Cursor	10 min	Cursor opens your repository and the agent answers in chat
2	Configure the agent’s gate	15 min	The agent runs `npm run verify` without an approval prompt and cannot read `.env`
3	Choose a model	10 min	You know which model runs, and change it only on evidence
4	Write project rules	10 min	Asked which rules apply, the agent names yours
5	Plan from a PRD	15 min	You approved a plan’s acceptance criteria in Plan Mode
6	Connect MCP servers	10 min	The agent calls one tool from one MCP server
7	Manage context	10 min	The agent reuses your canonical example
8	Build your first feature	20 min	Each criterion maps to a test that fails when the code is broken
9	Recover from agent mistakes	10 min	You have rolled back one agent change on purpose
10	Work with git and your team	15 min	Your pull request carries an evidence summary

Step 2 comes this early on purpose: every later layer points at the verify command. For the model, start on the one Cursor selects and switch only when your own tests show the work falls short; current names and prices are in the models hub.

How do you check that the Cursor setup works?

Commit a clean baseline first, so any uncommitted agent change is one git restore . away, plus git clean -nd to review new files and git clean -fd to delete them (or git stash -u to keep it all). Then run the gate yourself in a terminal at the repository root:

git status --short     # empty: nothing uncommitted before the agent starts
npm run verify         # your type check, lint and tests; must exit 0 on main

Fix or record a red verify first, or the agent “fixes” failures it did not cause. Then paste this into Cursor’s agent chat:

Audit this Cursor setup before I start real work. Do not edit any file.
1. List every project rule that applies to this repository and quote the
   line in each that names a build, test, lint or type-check command.
2. Run `npm run verify` once and report the exit code and the first error
   line of any failing check.
3. Tell me whether you needed my approval to run it.
4. List the MCP servers and tools you can call.
5. Try to read .env and report exactly what happened.
Finish with `git status --short`, which must be empty.

The setup passes when verify ran unprompted, .env was refused, the quoted rules are yours, and git status --short is empty.

How do you trust the first feature without reading every line?

The agent proves its work, and you check the proof. Write acceptance criteria before any code, paste them into Plan Mode, and approve the plan. Build one step per prompt with a commit after each, while a Cursor hook that re-runs verify when the agent finishes sends failures back to it.

You sign off on the criteria, a criterion-to-test table, and the scope from git diff --stat; CI re-runs verify on the pull request. Build your first feature walks through it, and evidence, not diffs explains why it scales.

Write the evidence summary for this branch's pull request. Do not change code.
- Each acceptance criterion mapped to its test, and whether that test
  failed when you broke the behaviour.
- The final pass/fail line of each check in `npm run verify`.
- `git diff --stat main...HEAD`, with a reason for every file outside
  the feature and its tests.
- Anything no test covers that a reviewer must check by hand.

What breaks in a first Cursor setup?

Symptom	Likely cause	Recovery
The agent asks before every test run	The run mode still asks for that command	Set a run mode that lets `npm run verify` run without approval (essential configuration)
The agent ignores your conventions	No rule, or it never loads	Fix it with project rules
The agent writes a new helper instead of yours	It never saw yours	`@`-mention one canonical example (context management)
Tests pass, but the feature is broken	The tests mock the broken part	Test through the real entry point (first feature)
The agent turns a test green by editing it	Nothing forbade it	Check `git diff --stat main...HEAD -- '.test.' '.spec.'` for committed steps (drop `main...HEAD` for uncommitted edits), revert, and forbid it in a rule
One prompt broke many files	The step was too large	`git restore .`, then `git clean -nd` to review new files and `git clean -fd` to delete them (or `git reset --hard <last good commit>` for committed steps), then ask for a smaller step (error recovery)
A tutorial says “YOLO mode”, “Auto-Run”, `.cursorrules`, or Background Agents	It predates Cursor’s renames	Use Run modes, Rules, and Cloud Agents instead

Where to go next after the Cursor quick start

For the wider path, follow the developer track and the Cursor overview; for other agents, see the Claude Code and Codex quick starts.

Essential configuration Verify command, run mode, rules, hook and secret exclusions

Build your first feature Acceptance criteria, Plan Mode, small steps and proof it works

Testing patterns in Cursor Make the tests strong enough to replace line-by-line reading