Cursor: Getting Started & Core Workflows
A six-chapter, practical Cursor learning path covering installation, first projects, repository exploration, edits and debugging.
- Author
- absequ
- Published
- Updated
- Category
- AI Tools
- AI Tools
- Cursor
- learning path
- core workflows
Six ordered tutorial chapters. Prerequisites: basic programming and Git; the core path starts from tool installation. The professional path assumes you have finished the core path or can demonstrate the same edit–verify–review loop.
Official tool documentation checked on 2026-11-06. Examples are original teaching exercises for a disposable notes project, not instructions to alter the absequ repository. Platform, account, model, privacy and permission controls can change; follow the cited current documentation for your installation.
On this page
1. Choose Cursor and prepare an editor workspace
Learning objectives: Understand an AI editor/agent workflow and prepare the local tools that generated changes will use.
Prerequisites: Basic programming and permission to use an AI tool on a disposable project. No prior knowledge of this tool is assumed.
Cursor combines an editor workspace with AI assistance and an agent that can inspect and change a project. Accepting a suggested line, asking a question and allowing an agent to run a command are different interactions. The editor view makes nearby code visible, but visibility is not proof that the assistant has read every relevant consumer.
Download the supported macOS, Windows or Linux distribution from the official quickstart/download path. Choose the build appropriate to your operating system and hardware; managed machines may require an approved distribution channel. Git and your application runtime remain separate prerequisites. This course uses a small JavaScript lab with Node built-in tests, not a particular framework or paid plan.
Practice in order:
- Check Git and a supported Node runtime in your normal terminal. Node 24 is a suitable teaching runtime for the lab; do not upgrade an existing project just to follow an editor exercise.
- Create a cursor-notes-lab directory and initialize Git. Keep real environment files, credentials and customer data outside the practice workspace.
- Decide whether to practice locally or through an approved remote-development setup. Opening a remote folder does not mean every extension, terminal tool or credential is configured identically on both machines.
git --version
node --version
mkdir cursor-notes-lab
cd cursor-notes-lab
git initExpected outcome: You have a disposable repository and a working runtime. You can distinguish editor actions from terminal commands and know which machine owns the project files before granting an agent access.
Common mistakes and troubleshooting: If an existing project requires a different Node version or package manager, follow that repository rather than this lab. Avoid experimenting in a workspace with uncommitted employer changes. AI features do not make an absent compiler, database or runtime available automatically.
Summary: Your environment is ready. Next install/sign in and open the lab with a known permission posture.
2. Install, sign in and inspect Agent controls
Learning objectives: Open the intended folder, select an authorized account and understand where edits and command approvals appear.
Prerequisites: Complete chapter 1: Choose Cursor and prepare an editor workspace.
Use the official installer for your platform, launch Cursor and sign in. Account/model availability and organization policies can differ; a model visible in another editor does not guarantee the same access in your workspace. Start with the lab folder through the editor file/folder controls. Importing settings can be convenient, but inspect inherited extensions and automation before trusting the workspace.
The current quickstart opens Agent with Cmd+I on macOS or Ctrl+I on Windows/Linux. Use the displayed command/keybinding if yours differs. Agent can edit files and use a terminal; Ask is the documented read-only choice for questions. Run Mode controls execution and sandbox behavior, so inspect its current settings rather than assuming the editor asks before every action.
Practice in order:
- Install from the official download link, sign in with the approved account and open cursor-notes-lab. Confirm the workspace folder name in the editor and the terminal working directory.
- Open Agent and choose a question-only task first. Inspect where proposed edits, command execution and the diff view appear before asking for a change.
- Review the current security/Run Mode controls. Keep approvals and restrictions appropriate to a disposable lab; do not enable broad execution because a terminal command is blocked.
First Agent request:
Explain what is in this workspace and which local tools the notes exercise
will need. Do not modify files, run commands or install anything.
Tell me which assumptions you cannot verify from the current files.Expected outcome: The editor is connected to the correct workspace and you can locate the assistant panel, terminal and change review surface. The question produces an evidence-based answer without being mistaken for permission to create files.
Common mistakes and troubleshooting: If a command works in your external terminal but not the integrated one, compare PATH, shell and remote environment before changing code. If account access fails, resolve the sign-in or organization policy rather than pasting API credentials into chat.
Summary: You can orient yourself in the editor safely. Next use it to create and test a tiny project.
3. Create a small function and inspect generated changes
Learning objectives: Give Agent a bounded file contract and use the editor diff to verify exactly what it produced.
Prerequisites: Complete chapter 2: Install, sign in and inspect Agent controls.
The first exercise implements addNote(notes, text), trimming a title, rejecting blanks and returning a new array. It is a pure-function lab, not a storage service. By restricting the task to two files and existing Node tooling, you can inspect all generated code without a package installation or provider setup.
Agent applies edits while it works, so review the resulting diff rather than assuming a final answer is the only output. A passing test matters only if the assertions express the intended behavior. For example, checking that the original list is unchanged detects accidental mutation; checking that an array exists does not.
Practice in order:
- Ask Agent to propose notes.mjs and notes.test.mjs, then create them under the supplied contract. Keep Git commits and dependency changes out of scope.
- Open each changed/new file and inspect it against the request. Use Git status to discover untracked files; do not rely on the visible diff alone.
- Approve node --test notes.test.mjs in the lab terminal. Read the output, then ask for a brief summary of verified behavior and remaining assumptions.
Create notes.mjs exporting addNote(notes, text): trim text, reject blank
titles, and return a new array with one { id, title } note. Do not mutate
notes. Add notes.test.mjs using node:test and node:assert/strict to check
trimming, blank rejection and immutability. Propose files before editing.
No packages, network, staging, commits or pushes.// notes.mjs — a reference to compare with your agent's result
export function addNote(notes, text) {
const title = text.trim();
if (!title) throw new Error('Title required');
return [...notes, { id: notes.length + 1, title }];
}
// notes.test.mjs
import { test } from 'node:test';
import assert from 'node:assert/strict';
import { addNote } from './notes.mjs';
test('trims the title without changing the input', () => {
const before = [];
assert.deepEqual(addNote(before, ' Learn agents '),
[{ id: 1, title: 'Learn agents' }]);
assert.deepEqual(before, []);
});
test('rejects a blank title', () => {
assert.throws(() => addNote([], ' '), /Title required/);
});Save the two labelled portions as separate files. The reference tests should report two passing tests with node --test notes.test.mjs. The lab uses sequential in-memory IDs only to keep this first exercise small; deletion, concurrent writers and durable identity require a separate data design.
Expected outcome: Two inspectable files implement the contract and the focused Node test command checks meaningful outcomes. You can explain the patch without needing Agent to narrate every line for you.
Common mistakes and troubleshooting: If the generated project adds a web server, narrow the task before continuing. If the test fails, inspect the actual assertion and command output rather than asking the model to declare the code correct. Suggested edits and tests should be reviewed as separate artifacts.
Summary: You have one complete edit-and-check loop. Next understand how selected-code editing differs across current and older Cursor versions.
4. Use selected-code context and understand legacy Inline Edit
Learning objectives: Choose a question, a selection-scoped edit or a broader Agent task without assuming outdated keyboard behavior.
Prerequisites: Complete chapter 3: Create a small function and inspect generated changes.
Older Cursor tutorials describe a separate Inline Edit box opened with Cmd/Ctrl+K. Current official help says that workflow has been replaced: selected code sent with the documented shortcuts becomes context in Agent. This course uses the current selected-code workflow. If an older installed version still exposes Inline Edit, follow that version UI and verify its edit scope before accepting changes.
Selection is context, not a permission boundary. Ask for a specific function-only change and review the entire diff afterward. Use Ask for an explanation without edits, or Agent for an approved patch. A small selected snippet may omit imports, callers or a shared type, so give the assistant a way to inspect the missing boundary rather than demanding a blind rewrite.
Practice in order:
- Open notes.mjs and select the addNote function. Send the selection to Agent using the editor control or the current documented Cmd/Ctrl+L or Cmd/Ctrl+K binding.
- First ask how immutability is preserved. Then request the bounded 80-code-unit title limit, preserving blank rejection and input-array behavior.
- Review all changed files, not just the selected lines. Add 79/80/81-character tests and run the focused check. Reject scope expansion into unrelated files.
For the selected addNote function, first explain its current mutation and
validation behavior without editing. Then propose a minimal change to limit
trimmed titles to 80 JavaScript code units. Preserve existing behavior.
Identify affected tests and wait for approval before making edits.Expected outcome: You can connect the selected code to a concrete task and explain why the diff stayed within its approved boundary. The lesson works without claiming that every installed Cursor version has the same Inline Edit UI.
Common mistakes and troubleshooting: If a shortcut opens something unexpected, inspect your keybindings and current official help instead of pressing more keys until edits appear. Selecting a function does not guarantee the agent cannot change another file; inspect the complete diff.
Summary: You know how to provide focused editor context. Next trace a larger codebase and understand what its search index does and does not prove.
5. Explore repositories and understand indexing limits
Learning objectives: Use symbol-driven search to build a verified source map without assuming the agent knows the entire repository.
Prerequisites: Complete chapter 4: Use selected-code context and understand legacy Inline Edit.
Current Cursor search documentation describes Instant Grep, a local search index used to find exact symbols and patterns. That is different from older descriptions of embedding-based codebase indexing. A local index does not mean opened source never reaches a model: relevant file content can still become request context. Check current data-use policies before opening sensitive files.
For engineering work, require a path from an entrypoint to a consumer and its tests. In Next.js, that might be a page, client component, server action and storage helper. Another framework may use a controller and service. The file tree, search results and an AI summary are clues; active imports and runtime entrypoints establish what actually executes.
Practice in order:
- Open an existing repository in a separate workspace and inspect its README and working-tree status. Preserve user edits and identify project rules before asking for changes.
- Use a distinctive function name or error string to ask Agent for a read-only trace. Require actual file references, validation points and the existing check commands.
- Open the cited caller and test. If a file is absent from results, inspect workspace root, generated/vendor content and search exclusions before concluding the implementation does not exist.
Read-only: trace note creation from its UI entrypoint through server
validation to storage. Use file and function references, distinguish
archived examples and identify tests. Do not read credential files, edit,
execute commands or contact external systems. State any search blind spots.Expected outcome: The source map is small enough to verify and identifies at least one real caller/test relationship. You understand which evidence came from a search match and which required reading the file.
Common mistakes and troubleshooting: An empty search result can reflect the wrong workspace or exclusions, not an absent feature. Do not assume local indexing is a privacy guarantee for all subsequent model requests. Avoid pasting environment files to make discovery easier.
Summary: You can explore a repository with measured confidence. Next debug and recover using the editor and terminal evidence together.
6. Debug a failure and review the final patch
Learning objectives: Connect a reproducible failure to a focused fix and retain a safe recovery path.
Prerequisites: Complete chapter 5: Explore repositories and understand indexing limits.
A useful debugging report names the expected behavior, observed result and reproduction command. For the title limit, show the failing 81-character test and ask Agent to isolate the guard responsible. Current Cursor has a Debug workflow for runtime investigation, but a small pure-function bug can often be resolved with a simple focused test.
Editor checkpoints can assist recovery, but their scope is not identical to a Git commit or a service rollback. Before restoring, inspect which agent edits and manual changes may be affected. The safest recovery from a wrong local patch is an understood corrective hunk, preserving unrelated work.
Practice in order:
- Supply sanitized failure output and ask for one hypothesis tied to source. Have Agent run only node --test notes.test.mjs for this reproduction.
- Review the minimal fix, the test evidence and any unexpected changed files. Distinguish terminal launch/sandbox problems from application assertions.
- Inspect git diff --stat, git diff --check and all untracked files. Summarize what was verified and what was not, then decide separately whether to stage or commit.
Expected: an 81-code-unit trimmed title is rejected. Observed: it is accepted.
Reproduce with the existing focused Node test. Identify the faulty condition,
make the smallest correction and verify the boundary cases.
Do not change unrelated files, weaken tests or reset the working tree.Expected outcome: The actual failing behavior has evidence before and after the correction. You can hand the patch to a teammate with a precise check list rather than an unsupported claim that the whole application works.
Common mistakes and troubleshooting: If you use Restore Checkpoint, review the official behavior and save any manual edits first. It cannot reverse a sent email or a database write. Do not rerun a deployment or provider call to debug a harmless local test failure.
Summary: You have completed Cursor core workflows. Continue to professional rules, cross-layer features, integrations and team operation.
References
Cursor quickstart — Cursor
Agent terminal tools — Cursor
Cursor Agent — Cursor
Search and indexing — Cursor