The Cursor course

This is a hands-on course, not a reference. It runs on one carried example project - budgetcli, a small self-hosted personal-finance API for tracking accounts, importing bank statements from CSV files, and flagging overspend - and every chapter takes a problem you’ll really hit (auto-retrieval pins the wrong files on a big repo, the agent reintroduces the same money bug, a refactor is worth doing but not one-at-a-time) and shows the exact Cursor move that fixes it. budgetcli is an illustrative scenario, not a story you need to have followed: this site ships no starter repository for it, every page restates the scenario facts it uses, and the substitutions section below maps each move onto a TypeScript repo you own.

This course is editor-first. Cursor is a GUI-first fork of VS Code, built by Anysphere and shipped as its own desktop app - so the first-class surface here is the editor you already know, with the AI bolted onto it. That’s a deliberate inversion of the Codex and Claude Code courses, which start at the terminal: here the editor is the spine and the CLI is a chapter near the end, not the other way round. The arc runs from your first in-editor edit out to headless and CI - and by the time it gets there, the review habit you build in the first hour is the part that hasn’t changed.

If you want the spec-level “what is this primitive” view, that’s Foundations - the course site’s per-tool reference pages - and, for the vendor half, Cursor’s own docs at cursor.com/docs. This course is the other half: the muscle memory. Read it start to finish to build up from zero, or drop into any chapter when a specific problem is in front of you.

The framework: capability, context, control, cost

Every coding agent you’ll meet, Cursor included, shares one shape of strength and blindness. It is extraordinary at the general - broad, fast, fluent across languages and frameworks - and blind to the particular: it doesn’t know your codebase, your conventions, or your domain. Four principles run through every chapter, and they’re worth naming up front because they name that gap and every move you make about it:

• Capability - what the agent brings to the gap: what it can figure out and accomplish with its model and tools. Model choice and delegation live here.
• Context - what it is missing: the information that isn’t in front of it when it decides - your conventions, your domain, the file it hasn’t read. Rules (standing instructions in your repo), briefs (short written task instructions), and skills (packaged procedures) feed it context.
• Control - how you bound what it does with both: what guides execution, enforces boundaries, or lets you intervene. Modes (Agent/Ask/Plan/Debug postures), permissions (enforced boundaries), and hooks (deterministic gates) bound it with control.
• Cost - what every attempt spends while you do it: money and usage, elapsed time, attention, and rework. The meter runs the whole time.

Context is the organizing theme: most of what you’ll build in this course is ways to get what you know into the agent’s context, and ways to check what came back. The other three frame the decisions around it - how much the agent can do, what stops it, and what it spends. Model choices spend capability exactly where it changes the answer. No lesson needs all four principles; the framework is a lens, not a template.

Before you start

• Cursor installed (download from cursor.com)
• A Cursor account - the free tier is enough to start; pages name a higher tier where one is needed (plans as of October 2026)
• Basic TypeScript familiarity
• Git fundamentals
• VS Code experience helpful (Cursor is a fork)
• A small TypeScript repository you own or can freely edit, standing in for the course’s illustrative budgetcli scenario - the substitutions below map the moves onto it
• jq and a disposable CI/VM environment for the later CLI and Cloud Agent chapters

All chapters live

The full curriculum is written start to finish. Read it in order to build up from zero, or jump straight to the chapter you need. Lessons may still get sharpened over time.

Verification scope

The volatile product claims in this course (modes, the @ menu, rule types, run modes, CLI commands and flags, plans) were checked against Cursor’s primary documentation between 2026-09-19 and 2026-09-22 (plans, models, rule types, run modes and CLI flags re-checked 2026-10-23); each one carries an as-of date and links the page it was checked against. The transcripts show the shape of a turn; treat them as illustrative, not as captured Cursor runs. No starter repository ships for budgetcli, so the runnable steps are yours to execute on your own repo.

Lab setup and substitutions

The course uses budgetcli as a running scenario; no starter repository ships with this site. The examples are intentionally small enough to adapt - map every move onto a TypeScript repo you own:

• Any small TypeScript service with an import path and a few recurring conventions works as the budgetcli stand-in; a personal project you can freely edit is ideal.
• The rules chapter’s examples (money as integer cents, timestamps in UTC, Zod schemas for validation) map onto whatever conventions your repo actually has - write yours, not the course’s.
• The extending chapter wires a Postgres database and a live exchange-rate API as MCP servers; use any database or HTTP API you’re authorized to access, and don’t paste internal URLs or credentials into config you might share.
• The CI chapter wires a read-only check into a CI runner; any repo with a GitHub Actions-style workflow or similar works.

The curriculum

Eleven chapters, in reading order. Each is self-contained - it carries the example project one stretch further and restates the facts it needs - so start at the top, or pick the problem in front of you. Product surfaces like mode lists and menus shift between Cursor releases; every chapter dates its claims and links the primary doc, and the cards below name only what the final pages deliver.

1 · Getting started Your first hour: install Cursor, migrate your VS Code setup, meet the Agent sidebar and Tab autocomplete, watch one turn of the read-propose-review loop, and ship a first reviewed fix - a real CSV date bug - end to end.

2 · The daily edit loop The in-editor muscle that only exists because Cursor is an editor: Tab for the edits you can already see in your head, the Agent sidebar for the ones you'd rather describe, the bounded inline edit, @ to attach and / to run, the diff as your veto with checkpoints (saved states you can roll back to) behind it - dozens of small turns a day.

3 · Modes Switch posture deliberately: the built-ins are Agent, Ask, Plan, and Debug (as of September 2026) - Ask for read-only Q&A, Plan to agree the shape of a consequential change before it's built, Debug for bugs that resist a straight Agent pass. The settings-defined Custom Modes of older tutorials were removed in Cursor 2.1; today's skill-backed Custom Modes is a different, newer mechanism.

4 · Context Steer what the agent sees. Start from what Cursor already knows - Instant Grep, a search index that builds and runs on your machine - then the two gestures: pointing with the @ menu (files and folders, terminals, chats, diffs, the browser) and knowing when to let Cursor 2.0's self-gathering retrieval find what you'd have missed, and when a wrong guess is expensive enough to hand-pin instead.

5 · Models Spend where it pays. The per-chat picker, Auto routing everyday work across models, and a stronger model only when the reasoning earns it - plus what your plan actually bills (as of October 2026): Composer, Cursor's own agentic model; the per-model context limits current plans carry; and the legacy-plans-only Max Mode.

6 · Rules Stop Cursor reintroducing the same bugs by writing the project's standing facts down once: the four rule layers, the .mdc frontmatter and its four rule types, AGENTS.md as the portable plain-markdown path Cursor reads natively, the legacy .cursorrules file - and the sharp edge that a glob-scoped rule attaches only when the agent reads a matching file, so it can look silently skipped.

7 · Permissions, auto-run & the sandbox Set the blast radius on purpose. Two decisions: how much runs unattended - the run modes, Auto-review by default, then Allowlist and Run Everything - and what a running command can reach, with the OS-enforced Agent Sandbox as the wall and allow/deny lists as policy rather than guarantee.

8 · Parallel & remote agents Some work is worth doing but not one agent at a time. Three flavors of more-than-one-agent work: fan one prompt out to parallel agents, each walled off in its own git worktree; delegate scoped work to a subagent with its own context window; and hand whole tasks to Cloud Agents on remote machines - then the taxonomy of which flavor when.

9 · Extending: MCP, skills, commands & hooks Give the agent reach and structure: MCP servers to query systems it can't see, Agent Skills to package the procedures you keep re-explaining, custom slash commands for the prompts you keep retyping - and hooks as the deterministic gate that enforces policy whether or not the model cooperates.

10 · The CLI, headless & CI Take Cursor out of the editor. Install the CLI (the agent command; cursor-agent is its legacy alias), drive it interactively or headless with -p and explicit output formats, authenticate a script with CURSOR_API_KEY, wire a read-only check into CI, spawn Cloud Agents over the API, and let Cursor's Bugbot review every pull request.

11 · Daily workflow No new primitive - the last gap is between knowing a move and reaching for it without thinking: posture and model reflexes, the surface picked by the shape of the task, rules, skills, and commands written once into the repo, briefs that can't be misread. It ends in the look back across the whole editor-first arc and the job underneath all of it.

How to read it

Each chapter carries the same example project one stretch further, and the chapters build on each other: each one picks up a problem, adds a move to your repertoire, and hands off to the next. The order is deliberately editor-first: you start in the GUI where Cursor’s whole pitch lives, and only walk out to the terminal and CI once the in-editor habits are reflex.

So you get the most out of the course by reading it in order. But every chapter is also a direct entry: each page restates the scenario facts it needs, so you can drop in from a search with one specific problem in front of you and lose nothing but the accumulation.

What you won’t find is a fixed template stamped onto every chapter. Some need a long worked transcript, some a single setting and a warning, some a digression into why Cursor behaves the way it does. The shape follows the content, the way a good book varies its chapters.