Short answer: Cursor works from a technical specification: folder structure, data model, stack with versions, conventions and an implementation order. Use plan mode first so it proposes the plan before it writes code, name the files you want touched, and keep one rule file with your conventions so you do not repeat them in every message. Cursor writes code — it does not host your app, so the deploy step is yours.
No referral link here: this guide is the same whether or not you install Cursor.
What Cursor actually does well
Cursor is a code editor with AI built into the core: it can read your project, edit several files at once, run commands and follow project rules. For someone who already codes, it is the fastest of the tools on this list — and the least likely to produce something you cannot maintain.
It has no hosting, no database and no one-click deploy. It is a workshop for people who know what to build; the difference between a good and a bad result is almost entirely in how you brief it.
Why most Cursor prompts fail
- Chat-first instead of spec-first. "Add a settings page" gives you a page. A spec gives you a page that matches your architecture.
- No context. Cursor does not magically know your conventions — unless you @-mention the files or keep a rules file.
- Agent set loose without a plan. Letting it edit twenty files before you have read its approach is how refactors become rewrites.
- Everything at once. One enormous request produces a huge diff you cannot review and a bug you cannot find.
The structure Cursor responds to
| Block | What to include |
|---|---|
| Goal + scope | What this piece of work is, and explicitly what it is not. Scope creep is the main cause of unusable diffs. |
| Stack + versions | Framework, language, state management, styling, test runner. Versions matter: React 18 and React 19 are not the same briefing. |
| Structure | Where files go: src/features/<name>/, tests next to the code or in __tests__. |
| Data model | Types or interfaces, written out. It is cheaper than the agent guessing. |
| Conventions | Naming, error handling, no new dependencies without asking, comments in your language. |
| Order + acceptance | The steps, and how you will know each one works (tests, a command, a specific behaviour). |
Add user settings to my app and clean up the code while you are there.Prompt that produces a reviewable change
Goal: add a user settings page to this Next.js 15 app (App Router, TypeScript, Tailwind, Zustand, Vitest). Scope: settings only — do not touch auth, billing or the marketing pages. Do not refactor anything outside the files you must change.
Plan first: propose the file list and the approach in plain text and wait for my OK before writing code.
Data:
- UserSettings: { locale: 'es' | 'en', timezone: string, emailNotifications: boolean, weeklyDigest: boolean }
- Store it in the existing `users` table as a jsonb column `settings`, default values on first read.
- Validate with zod; the same schema on client and server.
Files:
- src/features/settings/SettingsForm.tsx — the form, one field per row, save button with pending and success states.
- src/features/settings/useSettings.ts — react-query hook: GET on mount, PATCH on save, optimistic update, rollback on error.
- src/app/api/settings/route.ts — GET and PATCH, session required, 401 when missing.
- src/features/settings/schema.ts — zod schema shared by both sides.
- Tests: src/features/settings/__tests__/settings.test.tsx (form renders with defaults, save calls the API, error shows the message).
Conventions:
- Server components by default, client components only where state is needed.
- No new dependencies without asking me first.
- Errors surface through the existing `toast()` helper, never `alert()`.
- TypeScript strict: no `any`.
Order: 1) schema and types, 2) API route, 3) hook, 4) form, 5) tests. Run `npm test` and `npm run lint` after each step and fix what breaks before moving on.
Cursor-specific rules
- Keep a project rules file. Your conventions (stack, naming, testing, language of comments) written once are followed in every request — and you stop repeating yourself.
- Ask for a plan before code. Reading five lines of plan is faster than reviewing a twenty-file diff.
- @-mention the real files. Context beats description: point at the components and types involved.
- Name what not to touch. The cheapest way to avoid collateral damage in a codebase you care about.
- One feature per request. Small diffs are reviewable; giant diffs get rubber-stamped and break in production.
- Ask for tests in the same request. The feature and its test in one pass is half the work of adding tests later.
Checklist before you press send
- Is the scope fenced off (including what is out of scope)?
- Are the stack and versions named?
- Are the files you expect listed?
- Are the types written out?
- Are your conventions stated — or in the rules file?
- Did you ask for a plan before code?
No referral link on this one: Inputo earns nothing if you install Cursor. The advice is the same either way.
Or let Inputo write it for you
Inputo's wizard produces a master prompt with the structure above — goal, scope, stack, data model, files, conventions and order — built from your answers in seven questions. Choose Cursor as your tool and you get the technical version of the brief, ready to paste into the editor.
Free to start; the full prompt is €5/month, or €5 once for 7 days.
Frequently asked questions
Is Cursor good for beginners?
Less than Lovable or Replit. Cursor assumes you can read code, install a project and use a terminal. If you cannot yet, start with Lovable; come back to Cursor when you want to own the code.
Cursor or Lovable for a real product?
Lovable to validate the idea fast, Cursor when the app has real users and you need maintainable code. Many projects start in one and continue in the other — with the same master prompt as the source of truth.
Does Cursor deploy my app?
No. Cursor writes and runs code; hosting is your call (Vercel, Netlify, a VPS). Our deploy tutorial covers the usual routes.