PD2V Web Cursor — from zero to pro
The basics at the top, the prompt cookbook at the bottom (open the A–E sections as you need them). The detailed parts are in expandable boxes — open what you need right now. Technical words have tooltips.
Cursor in 2 minutes
What it is
A code editor (IDE) with AI. It can write code itself, edit files and run commands.
3 main things
Tab = code completion. Ctrl+I = the Agent panel. Ctrl+L = sends the selected code to the chat with the Agent.
Agent
The Agent carries out the whole task for you. You check and approve.
Rules
Rules are rules that are always active — “answer in English”, “don't delete this”.
AGENTS.md
A file in the project root = a “README for AI”. Cursor treats it as a simpler kind of rules.
Skills
Skills are ready-made procedures for the AI.
MCP
MCP gives the AI new abilities (a browser, a DB, the cloud).
@-mentions
In the chat you type @ and add context: a file, a folder, a past chat, terminal output or changes in Git.
The first 5 minutes — a checklist
Download and install Cursor
From cursor.com. On the first launch, let it import your settings from VS Code (if you have it).
Sign in
Google / GitHub / email. Without signing in, the AI features don't work.
Open your project folder
Ctrl+O and pick the folder. Cursor treats it as your project.
Set yourself up once and for good
Customize → Rules → User Rules → paste your profile. You'll find a template for your role in the cookbook → A1.
Try three shortcuts
Tab accepts a suggestion. Ctrl+I opens the Agent panel. Select a piece of code and press Ctrl+L; the Agent gets it in the chat.
Ask your first question
In the chat, write: “Look through the project and tell me in 3 sentences what this repo does.”
3 main tools you'll recognise right away
Tab completes. Ctrl+L sends the selected code to the Agent. Ctrl+I opens the Agent, which knows your project. That's 80% of the work.
When to use what
Tab — autocomplete
The fastest. It completes several lines too. Tab accepts, Esc rejects.
Ctrl+L — the selection into the chat
Select code, press it and write what you want. You'll see the changes as a diff and reject what you don't want. Ctrl+K does the same. It used to open editing right in the code; Cursor replaced that with the Agent.
Ctrl+I — Agent
It changes several files and runs commands. You see every change in a diff and can undo it.
Where things live — settings
Cursor has two levels: user (all projects) and project (only the current one). That's the whole principle.
User (global)
Your Skills, subagents and MCP for all projects. Windows: %USERPROFILE%\.cursor\, macOS and Linux: ~/.cursor/. You set User Rules in the app via Customize → Rules.
Project
The rules of a specific repo. In the .cursor/ folder in the project root + the AGENTS.md file.
Exactly what's where
In the user folder
- skills/ — your own Skills
- skills-cursor/ — built-in Skills from Cursor (it manages them itself, don't edit)
- agents/ — your own subagents
- plugins/ — installed plugins
- mcp.json — MCP servers for all projects
The editor settings (settings.json, JSON as in VS Code) are elsewhere: Windows %APPDATA%\Cursor\User\, macOS ~/Library/Application Support/Cursor/User/.
In the project folder .cursor/
- rules/*.mdc — project rules
- skills/ and agents/ — the project's Skills and subagents (shared with the team via Git)
- mcp.json — project MCP servers
- hooks.json — automation
In the project root
- AGENTS.md — the project guide for AI
- README.md — the guide for people
- .env — secrets, must not go into Git
- .cursorignore — what the AI shouldn't read (on top of .gitignore, which Cursor respects by itself)
Rules — what, where and which rules to add
Rules are short instructions the AI gets automatically in every conversation. Three levels: user (in all projects), project (one project) and auto-attached (only for certain file types).
User (everywhere)
Customize → Rules → User Rules. Your language, OS, style and the things the AI shouldn't do without your consent.
Project
The files .cursor/rules/*.mdc. The conventions and prohibitions of a specific repo.
7 categories of rules worth having
A good set of Rules covers these 7 areas. Each one has an example of what to write there:
1) Language and communication
# Communication
- Answer in English. Keep technical terms as they are.
- Keep it informal.
- Short and to the point. No "certainly, happy to help".
- When you're missing information, ask. Guessing costs more time than a question.
2) Answer format
# Answer format
- For code edits, the diff first, then 2–3 sentences of explanation.
- For bigger tasks, a plan in bullet points first, only then the code.
- Break long texts up with subheadings.
- Don't use emoji unless I explicitly ask for them.
3) Code conventions
# Code
- Strict TypeScript. No `any` unless there's no other way.
- 2 spaces, no semicolons (Prettier default).
- Functional components + hooks (no class components).
- Naming: camelCase, components PascalCase, constants UPPER_SNAKE.
- Comments only when they explain **why**, not **what**.
4) Dependencies and libraries
# Dependencies
- Change versions in package.json only with my consent. A new library version can break the build.
- Add new libraries only when it can't be solved with what we already have.
- Prefer: zod for validation, zustand for state, TanStack Query for fetching.
- Don't use moment.js (date-fns instead) or lodash (native JS is enough). They needlessly grow the bundle.
5) Safety and prohibitions
# Safety
- Run destructive commands (rm -rf, git push --force, drop database) only with my consent. They can't be undone.
- Don't commit .env*, credentials.json, secrets.* and *.pem files. What gets into Git stays in the history.
- Don't write secrets into code; read them from process.env.*.
- Don't rewrite a migration that has already run. Make a new one.
- Into main/master only via a PR and after my confirmation.
6) Testing and checking
# Tests and validation
- For a new feature, always add at least one test.
- Always validate input from outside (URL, form, API) with zod.
- After a code change, run lint and show the output.
- Before a commit, check that `npm run build` passes.
7) Workflow (Git, commits, PRs)
# Git & workflow
- Commits in Conventional Commits: feat: / fix: / chore: / docs: / refactor:
- One commit = one logical change. Don't commit 5 things at once.
- Branches: feat/name, fix/name, chore/name.
- Before opening a PR: lint + test + build.
4 types of rules (Always Apply / Apply Intelligently / Apply to Specific Files / Apply Manually)
You pick the type in the menu next to the rule. Cursor then sets the header for you (description, globs, alwaysApply).
- Always Apply (alwaysApply: true) — active in every message and it even survives auto-summary. For the basic style, prohibitions, critical rules.
- Apply to Specific Files — active only for files that match the globs (e.g. only **/*.tsx).
- Apply Intelligently — the AI takes the rule when it decides from the description (description) that it fits. For less frequent procedures.
- Apply Manually — used only when you mention it in the chat with
@(e.g.@react).
A template for the file .cursor/rules/react.mdc (Apply to Specific Files)
---
description: Rules for React components
globs: **/*.tsx, **/*.jsx
alwaysApply: false
---
# React rules (active only for TSX/JSX files)
- Functional components, hooks instead of classes.
- Type props with an interface, not a type alias.
- No `useEffect` for simple calculations — use `useMemo`.
- Every component: 1 default export, max 200 lines.
A template for the file .cursor/rules/core-rules.mdc (alwaysApply: true)
This is the most reliable way to have critical rules in every message, even after the auto-summary of a long chat. It won't prevent mistakes completely, but the AI always has them in front of it.
---
description: The project's core rules — always in context.
alwaysApply: true
---
# Core rules (always active)
## Communication
- Keep it informal, answer in English.
- Short, to the point, no “certainly, happy to help”.
- Use she/her for yourself (or whatever you like).
## Only on my explicit instruction (hard to undo)
- `git push`, `git reset --hard`, `git commit --amend`
- Deploying to production, publishing versions
- Deleting files in `releases_archive/` or `.env*`
- Building installer packages (MSI, AppX, DMG)
## When you're not sure
- Ask. Better to ask 3× than to break production once.
⚠ Watch out for long chats — auto-summary and what survives
When a chat overflows the context window, Cursor replaces the old history with a short summary. At that moment the AI forgets everything that wasn't “permanent”. This typically happens after 1–3 hours of work in one chat.
What survives auto-summary and what doesn't
| Where the rule is | Survives the summary? | Note |
|---|---|---|
| User Rules (Customize → Rules) | ✅ Yes | Global, always injected. |
| .cursor/rules/*.mdc s alwaysApply: true | ✅ Yes | Per project, always injected. |
| .cursor/rules/*.mdc s alwaysApply: false | ⚠ Only when they're used | Apply to Specific Files, Apply Intelligently, Apply Manually. |
| AGENTS.md in the project root | ✅ Yes | Cursor treats it as the project rules. An AGENTS.md in a subfolder applies only when working with the files in it. |
| @-mentions (files, folders) | ❌ Mostly not | Context from past messages is lost after the summary. |
| Instructions from the chat (“from now on don't delete X for me”) | ❌ No | It belongs in Rules, not in one chat. |
AGENTS.md — the project guide for AI
A file in the root where the AI finds out straight away what the project is about, what the tech stack is, how to run it and what it definitely shouldn't do. The AI itself can create it for you — see prompt A3.
A ready-made AGENTS.md template
# AGENTS.md
## What this project is
In one sentence: what it does and for whom.
## Tech stack
- Node 20, TypeScript 5, Vite, React 18
- Cloudflare Workers (wrangler)
## Folder structure
- `src/` – frontend
- `worker/` – backend
- `docs/` – documentation
- `scripts/` – build and release
## How to run
```bash
npm install
npm run dev
```
## Conventions
- Commits: Conventional Commits (feat:, fix:, chore:)
- Change dependency versions only after asking.
- Before a PR: `npm run lint && npm test`.
## What to watch out for
- Don't delete files in `releases_archive/`, they're the only copies of old versions.
- Push to `main` only after confirmation; a push triggers a deploy.
How to steer the Agent — what to say, what not to say
The Agent can work on its own — read files, write them, run commands. So it doesn't cause needless damage or do needless work, follow these principles.
✓ What the Agent can do
Read the repo, edit files, run the terminal, search the web, control a browser, call MCP tools, generate images, commit, open PRs.
✗ What the Agent doesn't do well
Guess your intent without context. Make the right decisions without a plan. Keep a whole big repo in its head at once.
⚠ When to slow it down
Destructive commands (rm -rf, drop, force push), dependency changes, deleting history.
Techniques for steering the Agent
1) Start in Plan mode
For anything bigger than 2 files: switch to Plan, have it write a plan, check it, approve it. Only then switch to Agent.
I'm in Plan mode. Suggest an approach for [task].
I want:
- 5–8 steps, each = 1 commit,
- for each step: what changes and in which file,
- risks and open questions (ask me them).
Don't implement anything, just the plan.
2) Work step by step with checks
Carry out step 1 of the plan. When it's done:
- run lint and the tests,
- show me the diff,
- wait for my approval before you move on to step 2.
I want to check every step before the changes pile up.
3) Explicitly forbid destructive actions
For this whole task, without my consent:
- don't delete files, except the ones you create as part of the task,
- don't push to the remote,
- don't change package.json (versions or dependencies),
- don't run database migrations.
These steps are hard to undo.
When any of this is needed, stop and ask.
4) Give it an "error budget"
When lint or a test fails 2× in a row and you don't know why, stop
and tell me what you tried and where you're stuck.
Don't blindly try more and more edits.
5) Ask for evidence
You say it works? Show me:
- the exact commands you ran,
- the output (the relevant lines, not the whole log),
- how you verified it.
If you can't back it up, write "not verified".
6) Don't confuse the Agent with noise
Put one task in one message. Don't drag half the repo into the chat; add a specific file with @. A new task = a new chat (or at least a clear "forget the previous context, we're starting again").
What to say (✓) and what not to say (✗) — specific phrases
✓ Good phrases
“Show me the plan first, don't implement anything.”
“Do only step 1 and stop.”
“Show me the diff before applying it.”
“Check how the existing code in @[file] does it and stick to the same pattern."
“When you're not sure, ask.”
“Follow the conventions from AGENTS.md.”
✗ Problem phrases
“Do it however you think.” — it has no frame.
“Fix that bug.” — without context it guesses.
“Rewrite the whole project in…” — it ends badly.
“Do it as well as you can.” — subjective, it fantasises.
“When it's done, commit and push.” — it sends out unfinished and unchecked work too.
About you & communication style
User Rules contain a profile (who you are) and a communication style (how to talk to you). You'll find templates for different roles and styles in the cookbook → A1 and A2.
4 rules of good communication with AI
Be specific
Not “fix the bug”, but “in api.ts the function fetchUser returns 401 — add a token refresh".
Give context
Add files (by dragging or with @), paste the error, write what you've already tried.
Say the format
“Just the diff, no explanation.” “A plan in 5 points.”
Limit the scope
“Leave the backend alone, just the UI.” “Don't edit the tests.”
Modes: Agent / Plan / Ask / Debug
Agent writes and runs. Plan prepares a plan and doesn't change code. Ask only answers. Debug looks for the cause of a bug. You switch them in the menu by the chat or with Shift+Tab.
When to use which mode
Agent
Implementation, refactoring, setup. It changes files and runs commands.
Plan
It doesn't change code. A plan first, then the Agent. Good for a bigger task.
Ask
It only answers. Good for learning, code review and understanding the repo.
Debug
For tricky bugs. It suggests possible causes, adds temporary logs to the code, has you reproduce the bug, fixes the cause and cleans the logs up again.
Skills — ready-made procedures for the AI
A Skill is a folder with a SKILL.md file that describes how to do a certain type of task. The AI pulls it out by itself when it decides from the description that it fits. You run it by hand by typing / and the skill name in the chat. Prompt A5 writes your own Skill.
Where Skills live + a minimal template
- User (all projects): ~/.cursor/skills/<name>/SKILL.md or ~/.agents/skills/
- Project (shared via Git): .cursor/skills/ or .agents/skills/
- From plugins: they install with the plugin
- Built-in: ~/.cursor/skills-cursor/ is managed by Cursor itself, don't write anything there
The name in the header (name) must match the folder name. Cursor also loads skills from the .claude/skills/ and .codex/skills/ folders.
---
name: release-notes
description: Generates release notes from the commits since the last tag. Use it when the user wants release notes or a changelog.
---
# Steps
1. Find the last tag: `git describe --tags --abbrev=0`.
2. List the commits: `git log <tag>..HEAD --pretty=format:"- %s"`.
3. Group them into categories: Features / Fixes / Chore.
4. Return markdown ready for a GitHub release.
# Limits
- Don't make up features that aren't in the commits.
- Ignore merge commits.
Subagents — specialised helpers
The main agent (the one you're writing with) starts subagents by itself for partial tasks. They can run in parallel and each returns only the result, so they don't flood the main chat.
Built-in subagents and your own subagent
explore
It searches the code and returns what it found. Read-only.
browser
It controls a browser (UI tests, screenshots).
Your own subagent
The file .cursor/agents/<name>.md in the project, or ~/.cursor/agents/ for all projects. From the description (description) the Agent knows when to hand it a task.
---
name: code-reviewer
description: Reviews a finished change against the plan and looks for bugs. Use it after a feature is done.
model: inherit
readonly: true
---
Review the diff of the current change against the plan or the brief.
Look for bugs, missing tests and places where the change departs from the brief.
For every finding, write the file, the line and why it matters.
If you find nothing serious, say so. Don't make up findings.
MCP & Hooks
MCP servers give the AI new abilities (a browser, a DB, Cloudflare…). Hooks run scripts at a certain moment (e.g. lint after an edit). Adding an MCP server is in prompt A6.
Configuring MCP and Hooks
MCP — where to turn it on
- Customize in the side panel (installing from the Cursor Marketplace, turning servers on and off)
- Or .cursor/mcp.json in the project (shared with the team via Git), or ~/.cursor/mcp.json for all projects
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "C:/projects"]
},
"cloudflare-docs": {
"url": "https://docs.mcp.cloudflare.com/mcp"
}
}
}
@-mentions in the chat
You type @ and add a specific thing to the context: a file, a folder, a past chat, the terminal, changes in Git or the browser.
Types of @-mentions
Files and folders
@auth.ts or @src/components/. You decide exactly what the AI should read.
Selected code
Select a function and press Ctrl+L. A reference to exactly those lines is added to the chat.
@Terminals
Output from the terminal, for example the error from the last command.
@Chats
A past chat, when you're continuing older work.
@Commit / @Branch
Changes that aren't committed yet, or the difference of the whole branch against main.
@Browser
A browser in which the Agent opens and tests a page.
@Web and @Docs are no longer in Cursor's current documentation.Files and the workspace
Cursor sees everything in the folder you have open (the workspace). You can drag files into the chat, add them with @, or have a task file that the AI works through in order.
Drag & drop
Grab a file in the left panel and drop it into the chat. The same for images — the AI sees them as input.
@ and the file name
Typing @ opens the suggestions. Faster than dragging.
Copying text
Paste an error from the terminal or a piece of code as ordinary text.
A task file
Prepare tasks.md, then say: “carry out the tasks from @tasks.md”. See C6.
Practical workspace tricks
Workspace = the folder the AI sees
Everything inside the open folder is available to the AI. The AI ignores subfolders like node_modules, dist, .git (Cursor respects .gitignore and the .cursorignore file).
Several projects at once
You can open several folders as a multi-root workspace (File → Add Folder to Workspace). The AI then sees both — useful for a frontend + backend in separate repos.
A tasks.md template
# Tasks for Cursor — project [name]
## Priority 1
- [ ] Add a dark mode toggle to `Header.tsx`
- [ ] Fix focus-visible in the Menu (a11y)
- [ ] Generate a new app icon into `public/icons/`
## Priority 2
- [ ] Write tests for `utils/date.ts`
- [ ] Add sitemap.xml and robots.txt
## Deploy
- [ ] `wrangler deploy --env=preview`
- [ ] Check it in the browser
- [ ] `wrangler deploy --env=production`
Then in the chat: “Carry out the tasks from @tasks.md one by one, commit after each and tick it [x].”
AI-generated images — where they're saved
The Agent creates them with its own tool (Cursor 2.4 and newer). The default place is the assets/ folder in the project, and you'll see the image right in the chat too. If you want it elsewhere, write the path into the prompt.
Recommended structure
public/images/ — images for the website
public/icons/ — app icons
assets/ — where Cursor saves when you don't say otherwise
docs/images/ — images for the documentation
What to check
After generating, click the path in the AI's answer — Cursor opens the file. Or in the terminal dir public\images (Windows) / ls public/images.
Best practices — formats, sizes, retina
- Put images for the website into public/ — they're then available at the URL
/images/xyz.png. - Convert big images to WebP/AVIF (“convert
public/images/*.pngto WebP, quality 85, using sharp"). - Always generate icons 2× bigger than you need (retina).
- Bulk edits: “Shrink all images in
public/images/to a max width of 1600px."
Git & PRs
The AI can handle commits, branches and pull requests. The prompt is E6.
Specific instructions for the AI
- “Make a commit with a description based on the diff.” — a message following Conventional Commits.
- “Create the branch
feat/login, move the changes there, open a PR." - “Resolve the merge conflicts in
@[file]."
git push --force and deleting branches only with your consent. They rewrite or delete history that may not be recoverable.
Terminal & long-running tasks
The Agent has its own terminal. Dev servers run in the background. Windows: write in Rules that you use PowerShell.
PowerShell specifics (Windows)
- In Windows PowerShell 5.1 you don't chain with
&&but with a semicolon;. - A frozen process: “Stop the process on port 5173 and start the dev server again.”
Safety & secrets
Never paste tokens and passwords into the chat. Put them into .env, read them via process.env.*, never into Git.
A safety checklist
- In Rules: “Don't commit
.env*orcredentials.json." - MCP and Hooks have real access — check what you allow them.
- Before publishing, go through the history:
git log -p | grep -iE "token|secret|apikey"(in Git Bash), or let the AI do it. - On GitHub, turn on protection against uploading passwords (push protection), see GitHub — passwords and keys.
What to avoid in a prompt
Vague instructions, prohibitions without an alternative, “do it all at once”, error messages without context and tasks the AI has no tool for right now (a page behind a login, things outside your computer).
A detailed list of phrasings that confuse the AI or lead to a bad result
🚫 “Make it nice / better / cool”
The AI doesn't know what nice is. Instead: “use the design tokens from globals.css, stick to an 8px grid, 12px rounding, AA contrast".
🚫 “Fix all the bugs in the app”
Too broad, the AI starts changing random things. Be specific: “in @UserForm.tsx clicking Submit twice causes a duplicate POST — find it and fix it".
🚫 Negations without an alternative
“Don't use any” — OK, but what instead? Without an alternative the AI often uses a worse option. Write “instead of any use unknown and narrow the type with a check”.
🚫 Pasting a long error without context
500 lines of stack trace and “fix it”. The AI has no chance. Add: what you were doing, what output you expect, since when it hasn't worked, and only the first 20 lines of the error.
🚫 “You're a programmer, do X, Y, Z…” (10 roles)
Putting a role into the prompt only makes sense once and briefly. A long “you're a senior developer, designer, architect, DevOps…" makes the output worse. Leave it in User Rules.
🚫 “Do the whole feature + tests + docs + PR + deploy”
One big step = big hallucinations. Split it into 3 steps: 1) write the function, 2) run it and show the output, 3) now the tests. The AI can verify between the steps.
🚫 “Read the whole repo and understand it”
It won't understand, it'll just burn the context. Add a specific file or folder with @, or “find where authenticate() is defined — use grep".
🚫 “Find it on the web” without a source
The Agent can search the web and open a browser. But when it can't get to a page (a login, a block), it may make up what's probably there. Ask for a link to the source, or paste the text into the chat yourself.
🚫 Mixed languages in one prompt
“Write me a function that handles login, a vrátí JWT token s user id and some expiry.” The AI then mixes languages in the output too. Stick to one language in one thread.
🚫 “It surely works, run it in production”
The AI sometimes claims something works even when it didn't run it. Always verify locally (“run it and show me the output”) before you commit.
Common beginner mistakes
Too much context, no plan, blind Accept All, zero Rules, mixed languages, auto-run on dangerous commands.
What to do instead
Too much context
Instead of “read the whole repo”, add specific files with @.
No plan
For a bigger change, start in Plan mode.
Blind Accept All
Look through the diff.
No Rules
10 minutes of writing, years of benefit.
Mixed languages
Want answers in your language? Put it into Rules + into the first prompt.
Dangerous auto-run
Allow automatic command running only for safe things (lint, test).
A keyboard shortcut cheat sheet
Ctrl+I Agent · Ctrl+L selection into the chat · Shift+Tab modes · Ctrl+P file · Ctrl+Shift+P Command Palette · Ctrl+` terminal. On a Mac, Cmd instead of Ctrl.
A bigger overview
Chat & AI
Ctrl+I — open / close the Agent panel
Ctrl+L or Ctrl+K — selected code into the chat
Shift+Tab — switch mode (Agent, Plan…)
Ctrl+/ — switch the model in the chat
Ctrl+Enter — accept all suggested changes
Ctrl+Shift+Backspace — reject all
Tab — accept a completion suggestion
Esc — cancel a suggestion
Editor
Ctrl+P — open a file
Ctrl+Shift+P — Command Palette
Ctrl+B — sidebar
Ctrl+` — terminal
F2 — rename
Glossary
The same definitions as in the tooltips, just all together.
- IDE
- A program for writing, running and debugging code. Cursor and VS Code are IDEs.
- Workspace
- The working folder open in the editor. The AI has all the files in it at hand.
- Repo / repository
- A project folder versioned in Git. Code + the history of all changes.
- Git
- A system for versioning code.
- Commit
- One saved change in Git with a description. Like a “save” in a game.
- Push
- Sending commits to a server (GitHub).
- Branch
- A parallel version of a project.
- Merge
- Merging two branches.
- PR / Pull Request
- A proposal to merge. A colleague approves it, then it gets merged.
- Terminal
- A window with text commands (ls, npm, git). Also shell / console.
- Lint
- An automatic check of style and errors.
- Test
- A short program that checks a function does what it should.
- Build
- Turning the source into the final version (
dist/). - Deploy
- Uploading the finished version to a server.
- Stack
- The set of technologies used (React + Node + Postgres).
- Frontend
- The part of an app the user sees.
- Backend
- The part of an app that runs on a server.
- API
- An interface for communication between programs.
- Token
- An access key to an API. Like a password.
- Diff
- The difference between two versions.
- Refactor
- Rewriting code without changing its behaviour.
- Scaffolding
- Generating the skeleton of a project.
- Responsiveness
- A website/app adapts to the size of the screen.
- a11y
- Accessibility — access for people with disabilities.
- CI / CI/CD
- Automatic tests/build on every push.
- Agent
- An AI that carries out tasks itself.
- Subagent
- A helper AI that the main agent starts.
- Rules
- Instructions the AI gets automatically.
- Skill
- A procedure the AI loads when it's needed.
- MCP
- Model Context Protocol. Connecting external tools.
- Hook
- A script run at a certain moment.
- .env
- A file with secrets. Never into Git!
- JSON
- A text format for structured data.
- Markdown
- A text format for nicely formatted text without HTML.
- Model
- The AI “brain” you pick in the chat (Claude, GPT, Gemini…). Each one is strong at something different; the overview is in Which AI for what.
Prompt cookbook
Ready-made prompts in the logical order you'll use them in. Every section A–E is expandable — click the one you need. In the prompts, replace anything in [square brackets] with your own.
A · Setup & profile
One-time setup — a profile for your role, the communication style, AGENTS.md, a Rule, a Skill, MCP.
B · New project
From an empty folder to a running website/app.
C · Existing project
Download, edit, recycle old ideas, add a feature.
D · Images
Icons, hero images, SVG, variations. Where they're saved.
E · Debug & deploy
Fixes, performance, tests, deployment, PRs.
A. Setup & profile 6 prompts
Setting up your profile, the communication style, AGENTS.md, a Rule, a Skill, MCP.
Where: Customize → Rules → User Rules. Pick the role that suits you best and copy the template. Adjust the details ([square brackets]) and save.
# About the user
- Name: [Your name]
- Role: Frontend developer
- OS: [Windows 11, PowerShell] / [macOS zsh]
- Stack: TypeScript, React / Next.js, Tailwind, shadcn/ui
- State: Zustand / TanStack Query
- Tests: Vitest + Testing Library + Playwright
- Hosting: Cloudflare Pages / Vercel
# What I care about
- Type safety, clean components, a11y, performance (LCP/TBT/CLS).
- The design system and consistency.
# What I do less / ignore
- Deep backend (databases, infra) — I stay on the FE layer.
# About the user
- Name: [Your name]
- Role: Backend developer
- OS: [Linux / macOS / Windows WSL]
- Stack: Node.js + TypeScript, Hono / Express, Postgres + Prisma
- Alternatives: Go (sometimes), Python (data scripts)
- Cloud: AWS / Cloudflare Workers / Fly.io
- Tests: Vitest / Jest + Supertest
# What I care about
- Clean API design, validation (zod), error handling, observability.
- Database migrations, indexes, query performance.
# What I do less / ignore
- CSS and visuals — in the UI I'm only there for function, not design.
# About the user
- Name: [Your name]
- Role: Fullstack / indie developer
- OS: [Windows 11, PowerShell 7]
- Stack: TypeScript all the way — Next.js / React, Hono, SQLite/Postgres
- Cloud: Cloudflare (Workers, Pages, D1, R2, KV)
- Desktop: Electron / Tauri, Mobile: Expo
- I work alone on smaller projects; I prefer fast and clear solutions.
# What I care about
- End-to-end function, deploying with one command, monitoring.
- Minimal infra — serverless, edge.
# What I don't want
- Micro-frameworks just because they're "in". I prefer proven ones.
# About the user
- Name: [Your name]
- Role: Designer / UX
- OS: [macOS]
- Tools: mainly Figma, sometimes Photoshop. In Cursor I only do light code.
- Code I know: HTML, CSS, Tailwind. JavaScript only a little.
- I work on: a design system, icons, prototypes, landing pages.
# How I work
- I'll often send you a screenshot or a Figma link and want an implementation.
- Explain code to me simply; treat me as a junior developer.
- Suggest less code (vanilla + Tailwind) rather than complex stacks.
# What I don't want
- Bash/CLI tricks — explain slowly what the command does.
# About the user
- Name: [Your name]
- Role: Programming student
- OS: [Windows / macOS]
- I'm learning: [Python / JavaScript / Java]
- Level: lower intermediate; I know variables, functions, classes, Git basics.
# How I work
- Explain why we're doing what we're doing. I want to understand, not copy.
- When you write code, add comments to the non-obvious parts.
- Now and then ask me a check question to see whether I understand.
- Language: [English] / [English, with technical terms explained].
# What to avoid
- Don't give me the finished solution right away; give me a frame first and let me try.
- Don't use advanced tricks without explaining them (async, decorators...).
# About the user
- Name: [Your name]
- Role: Complete beginner — I can barely code
- OS: [Windows 11]
- Goal: [build a personal website / make a simple app / understand it]
# Communication style
- Write in English, talk as if you were explaining to a colleague in their first week of programming.
- Explain every technical term (IDE, commit, API, framework…).
- For terminal commands, always tell me exactly what will happen and why. Otherwise I don't know what I'm allowing.
- When there are several options, decide for me with a simple reason.
# What to avoid
- Don't go off on independent experiments. Ask before every bigger action.
- Don't use abbreviations (a11y, CI/CD, SSR…) without spelling them out.
- Don't run destructive commands (rm, drop, force push) at all. They can't be undone and I wouldn't know what broke.
# About the user
- Name: [Your name]
- Role: Musician / creative / content creator
- OS: [Windows 11]
- What I do: AI music, videos, graphics, sometimes a website around my work
- Programming: the basics, I can find my way around, but I'm not a developer
# What I need in Cursor
- Build and edit a personal website / landing page for my work
- Generate graphics (icons, covers, thumbnails, banners)
- Help with small scripts (FFmpeg, batch renaming, conversions)
- Sometimes publishing (Cloudflare Pages, GitHub Releases)
# Communication style
- Write in English, briefly and practically. Break the steps down into numbered steps.
- When you suggest a technical solution, also say "why you're choosing it over X".
- When generating images / graphics, be precise — colours, sizes, style.
# What to avoid
- Don't run anything destructive.
- Don't add dependencies without my consent.
# About the user
- Name: [Your name]
- Role: Data analyst / Data scientist
- OS: [macOS / Linux]
- Stack: Python (pandas, polars, numpy), sometimes R, SQL (Postgres/BigQuery)
- Notebooks: Jupyter, VS Code notebooks
- Visualisation: matplotlib, plotly, possibly Observable
# What I care about
- Reproducibility (seed, environment, uv / poetry / conda).
- Clean dataframe pipelines, type hints.
- Quick exploratory analysis (EDA).
# Communication style
- In English, technical terms as they are.
- For queries I prefer the table schema first, then the SQL.
- For visualisations: 1 chart = 1 message, not 10 lines in one.
# What to avoid
- Don't show me pandas patterns from 2018 (reset_index everywhere...).
- Don't use matplotlib's default colours; stick to my palette.
# About the user
- Name: [Your name]
- Role: [Product Manager / Marketing / Content]
- OS: [macOS / Windows]
- Technical background: I can find my way around, but I don't write code
# What I do in Cursor
- I write and edit documentation (markdown, GitHub wiki).
- I prepare texts, landing pages, email templates.
- Sometimes light website edits (copy, SEO, meta tags).
- Prototypes / mock-ups of screens; with AI I make what I need to show.
# Communication style
- Write in English. No needless jargon.
- Explain a technical problem in terms of business impact.
- For code changes: always tell me whether it breaks anything for users.
# What to avoid
- Don't run anything that changes the database / production without consent.
- Don't change commits that are already pushed.
Where: the same Rules file, under the profile (A1). It sets how the AI talks and writes.
# Communication style — brief
- Answer in English, keep it informal.
- 5 sentences at most, unless it's a plan or a review.
- No "certainly, happy to help", no waffle.
- For code edits: the diff at the top, 1–2 sentences below it.
- When you're missing something: 1 question, not 5.
- No emoji.
# Communication style — mentor
- Answer in English, keep it informal. Act like a patient mentor.
- Explain why, not just how. For every code change, 1 sentence on the reason.
- For more complex concepts, add an analogy from everyday life.
- Now and then ask me a check question ("do you see why…?").
- When you see me doing something unusual, ask whether it's intended.
- No emoji, no hyperbolic praise.
# Communication style — friendly
- Answer in English, informally, relaxed but professional.
- Feel free to sum up in one sentence "ok, I'll try it like this" and go for it.
- You don't have to be curt; allow yourself a short aside for context.
- Humour yes, but not forced.
- Emoji only minimally (✓ ⚠ — at most).
# Communication style — expert, formal
- Answer in English, formally.
- Act like a senior with 15 years of experience.
- When suggesting solutions, mention 2–3 alternatives and compare their pros and cons.
- Refer to specific library versions, RFCs and specifications. Mark what you haven't verified.
- Use precise terminology (immutability, idempotence, referential transparency).
- No small talk, no emoji.
# Communication style — bilingual
- Main language: [your language, e.g. Spanish].
- Don't translate technical terms if it makes the meaning less precise
(e.g. leave "closure", "side effect", "race condition" in English).
- Write commit messages and PR descriptions in English.
- Variable / function names in English, comments in the code in [your language].
- Keep it informal.
# Communication style — show me everything
- Answer in English, keep it informal.
- I want to see your reasoning: for non-trivial tasks, write a short "train
of thought" (hypotheses, what you considered and rejected).
- Before running any command, show me the exact text and the expected output.
- After running it: what happened (success / error), the relevant part of the log,
how you verified it.
- When you come across something interesting along the way (outdated code, inconsistencies),
don't fix it, just write it down in a list of “questions for later”.
# Universal prohibitions
- Don't make up APIs, libraries or functions. When you don't know something, say so.
- Don't use emoji unless I explicitly ask for them.
- Create new files only when needed. Otherwise edit the existing ones.
- Don't run rm -rf, drop database or git push --force. They can't be undone.
- Change versions in package.json only with my consent.
- Don't commit .env*, credentials.json or tokens.
Where: the Agent chat (Ctrl+I) in the project. Agent mode.
Explore this project and create an AGENTS.md file in the root.
It should contain:
1) What the project does (1–2 sentences).
2) The tech stack (languages, frameworks, cloud).
3) The folder structure with a short description of each.
4) How to run it locally (exact commands).
5) Conventions (commits, naming, lint/test).
6) What the AI should watch out for in this repo (what not to delete, what not to run, and why).
Before you start writing, go through package.json, README.md and the config
(e.g. wrangler.jsonc) and look into src/ and scripts/.
Mark what you can't read from the code for sure as [verify], so I can fill it in.
At the end, show me the diff and wait for confirmation.
When: the AI keeps doing something wrong — teach it with a rule.
Create a project rule for me in `.cursor/rules/[name].mdc` for this:
[a description of the problem or habit — e.g. "always validate input with zod",
"components always with an error boundary", "Tailwind instead of inline styles"]
Requirements:
- short (max 20 lines),
- with a YAML header (description, globs, alwaysApply),
- with 2–3 good and 2–3 bad examples,
- pick the rule type (Always Apply, Apply to Specific Files, Apply Intelligently
or Apply Manually) based on when it should apply, and say why.
Show me the content of the file and wait for confirmation before you create it.
When: you keep repeating the same more complex procedure.
Create a user Skill for this procedure:
[the name and a description of the procedure — e.g. "release-to-cloudflare":
1. git pull, check lint+test,
2. bump the version in package.json,
3. npm run build,
4. wrangler deploy,
5. create a git tag and release notes from the commits.]
Requirements:
- path: ~/.cursor/skills/[name]/SKILL.md
- YAML header: name (the same as the folder name) and description
(what the skill does and when to use it; that's how the Agent finds it)
- sections: Steps (numbered), Limits, A check at the end
- language: English.
Show me the full content of SKILL.md before creating it.
Where: Customize in the side panel, or .cursor/mcp.json.
I want to add the MCP server [name — e.g. "Playwright" or
"Cloudflare Docs"]. Explain to me:
1) What this server does and why I'd want it.
2) How to turn it on (Customize vs. mcp.json) — show the JSON.
3) What I need as secrets / tokens and where to put them.
4) The security risks and how I can tell I'm installing the official server, not a fake.
5) 3 example prompts I can try with it right away.
B. New project 6 prompts
From an empty folder to a running website / app / backend.
Mode: Plan (nothing changes yet).
I want to make [the type of project — e.g. "a landing page for my product"
/ "an Electron desktop app" / "an Expo mobile app"
/ "a backend API in Hono on Cloudflare Workers"].
Stack: [Next.js + TypeScript + Tailwind + shadcn/ui]
Hosting: [Cloudflare Pages]
The use case in 2 sentences: [...]
A plan first, not code:
1) Which pages / screens / endpoints will be created.
2) The folder structure.
3) The key libraries with reasons.
4) A split into commits (5–8 steps).
5) Risks and questions for me.
Check the library versions in the current documentation, not from memory.
Carry out step 1 of the plan (scaffolding):
- Initialise the project according to the stack.
- Set up lint (ESLint), formatting (Prettier), a simple CI workflow.
- Add .gitignore, a README with a quick start, AGENTS.md (brief).
- Make sure `npm run dev` works.
When it's done:
- Run lint and the build, show the output.
- The first commit "chore: initial scaffolding".
- Wait until I tell you to move on to step 2.
Create a landing page for [project]:
- Hero (headline, subtitle, 2 CTAs).
- Features: 6 tiles (a 3×2 grid).
- How it works: 3 steps.
- FAQ (accordion).
- A footer with links.
Design: [dark, primary #7C9CFF, bg #0B1020, accent #32D2A8].
Animations: subtle, respect prefers-reduced-motion.
Responsive from 320px. A11y: roles, alt, AA contrast.
Components in `src/components/`, the page in `src/app/page.tsx`.
The file tree first, then the implementation, then the diff.
Design a data model for [my feature]:
Output:
1) A Prisma schema (models, relations, indexes).
2) A UI state machine (loading / empty / error / success).
3) API endpoints (method, path, auth, input/output).
4) What goes in the Zustand store (client) vs. the server.
Don't implement anything. At the end, ask me 3 questions before we move on.
Build me an Electron app:
- a 1280×800 window, a custom title bar,
- IPC channels "project:open" / "project:save",
- auto-update with electron-updater from GitHub Releases,
- builds for Windows (nsis) and macOS (dmg).
Structure: src/main, src/preload, src/renderer (React + Vite).
Write package.json, the electron-builder config and a working skeleton.
Prepare GitHub Actions for signed builds.
Certificates and passwords only via GitHub Secrets, never in the repo.
A new Expo (React Native) app [name]:
- expo-router, a tab layout: Home / Explore / Profile,
- dark + light theme, persisted in AsyncStorage,
- a login screen (UI, no backend),
- an icon and a splash placeholder,
- strict TypeScript.
Small commits: scaffold → navigation → theme → screens.
Stop after each step so I can check it.
C. Existing project 6 prompts
Download from GitHub, take in the content of a live website, recycle ideas, add a feature, modernise, complete the tasks from tasks.md.
Download the repo [URL — e.g. https://github.com/user/project.git]
into this folder and get it ready for work:
1) git clone and cd into the folder.
2) Check the Node version, recommend the right one.
3) Install the dependencies, start the dev server.
4) Explore the structure and create AGENTS.md (A3).
5) Sum up for me:
- what the project does,
- where the main UI code is,
- where the deploy configuration is,
- gotchas.
At the end, ask what to edit first.
Only for your own website. With someone else's, take inspiration, but don't copy texts or graphics.
I have an old website online: [URL].
I only want the ideas and the content, not scraping the code.
1) Go through the main pages (homepage, about, pricing, FAQ).
2) Pull out the headings and text blocks (word-for-word quotes into `old-content.md`).
3) Identify the IA (information architecture): which sections.
4) Write `content-plan.md` — what to use, what to rephrase, what to drop.
5) Leave a note on the colours / fonts of the old website.
It's my own website; I can use its texts.
Set up a new website following B1–B3.
Use the ideas from `old-content.md` and `content-plan.md`:
- rephrase the texts into a more modern tone,
- we can keep or simplify the IA (Home / Features / FAQ / Contact),
- don't copy the colours and typography; make a new design following the brief:
[minimalist, whitespace, sans-serif, primary #7C9CFF, aqua accents].
I'll put the old images into `public/legacy/` and say what to use.
A plan of changes against the old version first.
I want to add a feature to the app: [a description in 1–2 sentences].
1) Explore the relevant code (start where a similar feature is today).
2) A plan in 3–7 steps, each = 1 commit.
3) Point out the tests we need to add / update.
4) Ask at most 3 questions before we start.
Don't implement anything yet.
Check @[src/legacy/] and suggest a modernisation:
- converting class components to functional + hooks,
- replacing outdated libraries,
- types (TS) where they're missing,
- splitting files that are too big.
Output:
1) A table "file | problem | suggested change | impact".
2) Priorities (quick win / medium / big refactor).
3) Leave the public API (exports, props, endpoints) unchanged,
so the code that uses it doesn't break.
Analysis only, no code.
The trick: Prepare a tasks.md, and the AI works through it in order.
I have tasks in the file @tasks.md. Carry them out in order:
- work from the first unfinished one,
- each task = a separate commit,
- after the commit, change the status in tasks.md to "[x] done" with the date,
- anything unclear → stop and ask me.
Don't start the next task until the previous one is done and committed.
# A tasks.md sample
- [ ] Add a dark mode toggle to Header.tsx
- [ ] Fix a11y in the Menu
- [ ] Add sitemap.xml and robots.txt
- [ ] Replace the favicon with the new icon from `public/icons/app-icon.png`
- [ ] Deploy to preview
D. Images, icons & graphics 5 prompts
An app icon, a hero image, an SVG logo, a series in the same style, variations from a reference.
assets/ folder in the project. So give the exact path in the prompt (e.g. public/images/hero.png) and check it after generating.
Generate an app icon for "[name]":
- Shape: a rounded square, 1024×1024.
- Motif: [a stylised sound wave turning into a pixel].
- Style: flat vector, a subtle gradient, 2–3 colours.
- Palette: #7C9CFF → #9B8CFF, accent #32D2A8, bg #0B1020.
- No text, no people, no watermarks, no shadows around it.
- Clean, modern, readable even at 64×64.
Save it to `public/icons/app-icon-1024.png`.
Make the smaller sizes (512, 256, 128, 64) by shrinking this icon with a script
(e.g. sharp), not by generating new ones, so they're all the same.
A hero illustration (1920×1080, 16:9):
- Motif: [an abstract visualisation of music turning into an image —
wavefronts breaking up into particles, forming the silhouette of a landscape].
- Style: digital painting, cinematic, a subtle bokeh.
- Palette: deep navy #0B1020, magenta #9B8CFF, aqua #32D2A8.
- Composition: the subject on the left (rule of thirds), space for text on the right.
- Light: a rim light from the right, a darker top-left corner.
- No text, no watermarks.
Save it to `public/images/hero.png`.
Want a logo in code? You'll get a text SVG.
Create an SVG logo for "[name]":
- simple, 2 colours, modern,
- geometry: [a circle with a broken ring + a minimalist "M"],
- viewport 64×64, paths only, no raster bg,
- main #7C9CFF, accent #32D2A8.
Return:
1) The full SVG code (as text).
2) An inverted variant for a dark background.
3) Save it as `public/logo.svg`.
Generate 6 illustrations in a consistent style for Features:
- 800×600, a solid #0B1020 background (generators often can't do transparent PNGs),
- style: isometric 3D, pastel colours, minimalist,
- palette: #7C9CFF, #9B8CFF, #32D2A8 + grey accents,
- motifs:
1) fast uploads
2) cloud sync
3) offline mode
4) sharing
5) analytics
6) security
Generate only the first one and wait until I approve the style.
Then do the others with it as a reference, so they keep the same style.
Save them as `public/images/features/feature-01.png` ... feature-06.png.
After generating, sum up the paths and sizes.
Drag the reference image into the chat, then write the prompt.
[First drag the reference image into the chat.]
Create a variation of this image:
- keep: the composition, the main subject, the size (800×800),
- change: the palette to a cold one (blue-violet instead of orange),
- add: a subtle bokeh in the background,
- remove: texts and watermarks.
Save it to `public/images/variant-01.png`.
What to do when generating in Cursor doesn't work
- Check your Cursor version (image generation is available from 2.4).
- Error 429 means overload. Try again in a while.
- Let the AI write the prompt and generate elsewhere (ChatGPT, Gemini, Grok, Midjourney). The guides are in AI images.
Write me a detailed prompt for Midjourney, with a short explanation of each part below it:
- motif: [...]
- style: [...]
- what I don't want in the image (as the --no parameter)
- aspect ratio: --ar 16:9
Use only parameters the current version of Midjourney knows. Leave out those you haven't verified.
E. Debug, refactor & deploy 7 prompts
Systematic debugging, safe refactoring, performance, tests, deployment, PRs.
Tip: for bugs that are hard to reproduce, try Debug mode. It adds temporary logs to the code and cleans them up after the fix.
Bug: [what's happening, one sentence].
Reproduction: [the exact step].
Error:
```
[paste the stack trace / console]
```
1) List the 5 most likely causes (hypotheses).
2) For each: how to check it quickly.
3) Pick the most likely one, verify it, only then the fix.
Don't write code until you've verified the hypothesis.
Refactor @[file] so that:
- the public API stays identical,
- test coverage doesn't drop,
- the commit is split into small steps.
Rules:
- a plan first (bullet points),
- after approval, work one step at a time,
- after each, run the tests and show the output.
The website is slow.
Metrics: [LCP 4.2 s, TBT 800 ms, CLS 0.15].
Analyse:
- @app/layout.tsx,
- the bundle (what to measure, how),
- the network waterfall (preload / lazy),
- images (format, size, lazy).
Priorities: 1) quick win, 2) medium, 3) big refactor.
For each: an estimated improvement + a diff. Mark the estimate as an estimate,
and measure again after the change (Lighthouse), so we know what really helped.
Create tests for the function [name] in @[file]:
- Vitest + Testing Library,
- cover: the happy path, edge cases, errors,
- mock fetch with vi.spyOn(global, 'fetch'),
- name the tests in plain English in it("…").
Only a new test file. At the end, tell me how to run just these tests.
I want to deploy to [Cloudflare Pages / Workers / Vercel].
Check:
1) The build without errors and warnings.
2) ENV variables — what to set in the dashboard, what to commit.
3) The configuration (wrangler.jsonc / vercel.json / next.config).
4) Security headers (CSP, HSTS, X-Content-Type).
5) Sitemap.xml, robots.txt, OG images (1200×630).
At the end, the exact commands. Ask before deploying.
Make a PR from the current changes:
1) A new branch `feat/[description]`.
2) Commits in Conventional Commits.
3) Open the PR with `gh pr create`.
4) In the description:
- Summary (1–3 bullets),
- Screenshots (for a UI change),
- Test plan (a checklist),
- Risky things / breaking changes.
Don't push to main and don't overwrite anything with a force push.
The PR is there so I can see the changes before merging.
At the end, send me the link to the PR.
Here's the code to review:
<code>
[paste the code or mark the file with @]
</code>
Context: [the language and framework, what the code does, where it runs, what my priority is: performance / security / readability]
Role: You are a Staff Engineer and Tech Lead who does code reviews of production code. You keep an eye on clean code, security and performance. You're not here to praise me, but to make the code ready for production.
Task: Do an in-depth Master-Level Code Review of the code above.
Method (go through these points):
1. **Performance:** Time and memory complexity (Big O). Needless iterations, O(N²) traps, needless allocations.
2. **Security and edge cases:** null, undefined, an empty array, a huge input. SQL/NoSQL injection, XSS, race conditions.
3. **Architecture and SOLID:** Single Responsibility, depending on concrete implementations instead of abstractions, magic numbers and strings.
4. **Testability:** Can the code easily be covered by unit tests? If not (I/O, global state), how to separate it?
Output format:
A. **Summary:** 3 sentences on the overall state of the code.
B. **Problems found:** Labels P0 (critical), P1 (refactor), P2 (cosmetic). For each, the line or function, why it matters and a suggested fix.
C. **The refactored version:** A fixed, fully production-ready version of the whole function, no “the rest of the code goes here”. Follow the language's conventions and add doc comments where the logic isn't obvious. Keep the public interface and behaviour the same, apart from the fixed bugs. List every change of behaviour.
D. **Justifying the changes:** In bullet points, why the fixed version solves the problems from point B.
E. **How to verify it:** Tests or steps with which I can verify the fix.
Report only problems you actually see in the code. When you're missing context for the assessment (the calling code, data, a library version), say what's missing and don't guess.