# Master Cursor: From Install to Shipping Your First Feature > A step-by-step beginner's guide to installing Cursor, setting up conventions, and using it to ship real features in your codebase. > By Dave · 2026-08-28 > Source: https://otf-kit.dev/blog/getting-started-with-cursor-ai Cursor lives in the editor, not next to it. That is the entire pitch and it's a real one. Most "AI coding" tools bolt a chat panel to the side and call it integrated; Cursor is the editor with the model wired into the buffer, the selection, and the file tree. You select code, you type a sentence, the code changes. You don't copy a prompt into a website, you don't paste output back. For a working developer that single difference is worth more than every benchmark ever published — it's the difference between using a tool and demoing one. This post is the one I wish I had on day one: install Cursor, open a real codebase (not an empty folder), write your conventions *before* the first prompt, learn the three core interactions, and ship one feature end to end. The whole thing takes an afternoon. The single non-obvious move — giving the agent a written rulebook — is what separates "it generated plausible code" from "it generated code I can merge." ## 1. Install and open a real repo Download Cursor from the official site and sign in. The Pro tier is what you want for serious use; the free tier will cap you mid-session in a way that makes the tool feel worse than it is. Don't judge the product on the free tier. Skip the "new folder" temptation. Open a real project — a Next.js app, an Express server, anything with at least 20 files and a real dependency graph. The model is dramatically more useful when it can read the surrounding code and copy the conventions it finds. An empty folder is a stress test, not a workflow. Let the indexer finish. Cursor builds a vector index of your repo so that chat and agent mode can pull in the right files. It runs in the background; the spinner in the bottom-right tells you when it's done. The first thing most beginners do is start prompting before the index is ready and conclude the tool is bad. The tool is fine. Wait for the index. ## 2. The one thing beginners skip: write `.cursorrules` before your first prompt Here's the lesson that costs the most when you skip it. The model's default behaviour is to *invent conventions*. It will pick a state management library, a folder layout, a test framework, an error-handling style, and a name for every function — and it will pick differently every prompt. You end up with a codebase that has six ways to do everything, none of which match the rest of the project. The fix is a file at the repo root named `.cursorrules`. Cursor injects its contents into every prompt, automatically, in the background. You don't @-mention it, you don't paste it in. The model just reads it. This is the single highest-use thing you can do in the first five minutes. ```md # Project: SaaS dashboard # Stack outcome, not stack names: shared components across web and mobile # Owner: shipped product, not a demo ## Conventions - Components live in `src/components/`. One file per component. Co-locate the test in `__tests__/`. - Server actions return `{ data, error }`. Never throw across an action boundary. - Money is integer cents. Always. The number of bugs this prevents is not zero. - Use the design tokens from `@otfdashkit/tokens` for color, spacing, type. Hard-coded values are a code-review fail. - Database access goes through the typed query layer in `src/db/queries/`. No raw SQL in route handlers. ## What to refuse - Do not introduce a new dependency without flagging it. Prefer existing libs. - Do not "fix" a file outside the task. Stay scoped. - Do not add a comment that restates the code. ## Voice - Senior engineer. Terse. Code over prose. No "let me explain", no "happy to help". ``` Three things to notice. First, this is *outcomes* not libraries — "shared components across web and mobile" rather than naming every framework. The model can adapt as the stack evolves. Second, there is a "refuse" section. Without it, the model will "improve" code you didn't ask it to touch and the diff becomes unreviewable. Third, it has a voice line. The model matches the tone of the prompt; tell it the tone you want. Write this file, commit it, then open Cursor for the first time. Reverse this order and you will spend an hour deleting invented conventions. ## 3. The three interactions you actually need Cursor has a lot of surface area. Ignore most of it. Three interactions cover 90% of real work. **Inline edit (`Cmd+K`).** Select code, type what you want changed, hit enter. This is for surgical, local edits — rename this, add the type, swap the loop for a map, fix the off-by-one. It edits the buffer, you review the diff, you keep moving. Use it for anything you could have done yourself in under two minutes but don't want to. **Chat (`Cmd+L`).** A side panel. Use it for questions, explanations, and "what does this file do." It does not edit files by default — it's a thinking partner, not a doer. The right time for chat is when you are stuck and want a second opinion faster than reading docs. **Agent mode (`Cmd+I`).** This is the one people underestimate. You give it a multi-step task — "add a password reset flow that emails a token, expires after 1 hour, and updates the audit log" — and it edits multiple files, runs commands, reads errors, fixes them, and reports back. The quality is a function of three things: the `.cursorrules` file, how clearly you describe the goal, and how small the scope. Big vague prompts in agent mode produce big vague diffs. Small specific prompts in agent mode produce small specific diffs that you can actually review. The mental model: `Cmd+K` is your hands, chat is your head, agent mode is your junior engineer. Use each for what it's good at. ## 4. One end-to-end feature, start to finish Here is the workflow for shipping a real thing. The example is a "duplicate project" button on a SaaS dashboard. Real code, real steps. **Step 1 — scope it in chat.** Open the project page file in the editor. Hit `Cmd+L`, type: > Read `src/app/projects/[id]/page.tsx` and `src/db/queries/projects.ts`. I want to add a "Duplicate" button to the project header that creates a copy of the project, its tasks, and its members under a new name. Do not write code yet. Tell me what you'd touch, what edge cases you see, and what questions you have. This is the move beginners skip. You are *using the model to think*, not to type. Read its answer. Push back on assumptions. "What about the billing relationship?" "What about archived projects?" You are the engineer; the model is the rubber duck on steroids. **Step 2 — agent mode for the implementation.** Once the scope is sane, hit `Cmd+I` and give it the actual task: > Add a server action `duplicateProject(projectId, newName)` in `src/app/projects/actions.ts`. It should: 1) load the project by id, 2) deep-copy it plus its tasks and members under a new id, 3) set the new name, 4) return the new project id. Use the existing `db.transaction` helper. Do not modify the project header component yet — that is the next step. Notice: scoped, named function, single file, no scope creep. Agent mode will read the existing helpers and copy their style because your `.cursorrules` told it to. The diff is reviewable. **Step 3 — inline edit for the UI.** Select the project header JSX, hit `Cmd+K`, type: > Add a "Duplicate" button next to the existing "Edit" button. On click, prompt for a name, call the action, then router.refresh(). That's it. Three interactions, three files touched, one feature shipped. Total time: under fifteen minutes for a working dev. The output is in your style because the `.cursorrules` told the model what your style *is*. ## 5. What changes when the conventions are pre-written A `.cursorrules` file is one file, but it changes the economics of the whole tool. Without it, every prompt reinvents the project. With it, the first prompt and the fiftieth prompt look the same to the model — same conventions, same refusals, same voice. The output stops drifting. Your code reviews stop being a hunt for inconsistencies and start being a hunt for bugs, which is the job. This is also why the *content* of the file matters. "Use TypeScript" is noise. "Money is integer cents. Always." is the kind of rule that prevents a four-hour debugging session six months from now. The best rules are the ones written from a real scar. ![first prompt with no rules vs tenth prompt with .cursorrules](https://cdn.otf-kit.dev/blog/getting-started-with-cursor-ai/inline-1.png) ## 6. The part that doesn't change when the tool does Cursor is a fantastic tool. So was the last one, and the one before that, and the one before that. The thing that survives every tool churn is the convention layer — the documented decisions about how *your* codebase works, written once, enforced everywhere, legible to humans and machines. This is exactly why the kits we ship at OTF include `CLAUDE.md`, `.cursorrules`, and 20+ tested prompts at install time. Not because we think Cursor is risky — use Cursor, use Claude Code, use whatever ships next week — but because the conventions are the part that outlives the tool. The component is the same `