Cursor Prompts
GPTPrompts.AI Editorial
Tested 50 prompts on Cursor Pro and Pro Plus across 4 real codebases in May 2026 Β· Last updated May 28, 2026
Direct answer
Cursor prompts in 40 words
Cursor is Anysphere's AI-native VS Code fork. The Composer Agent (GA February 26, 2025) handles multi-file work; Cmd-K does single-file edits; Tab predicts next edits. Project rules in .cursor/rules persist context. MCP support shipped November 14, 2024.
Free copy pack
Jump straight to 50 copy-ready Cursor prompts
Ten categories sorted by Cursor surface and job (Composer Agent, multi-file refactor, debug from a stack trace, tests, code review, docs, MCP, .cursor/rules, Cmd-K micro-edits, migrations).
Open the 50-prompt libraryHow we tested this
How we wrote and checked these 50 prompts
We ran each prompt on Cursor Pro and Pro Plus across 4 real codebases between May 14 and May 26, 2026: a Next.js 15 / Drizzle app, a tRPC monorepo, a Python FastAPI service, and a Go CLI. Three things we watched. Did Composer finish the job with the named acceptance test passing. Did Composer modify only the intended files. Did the project rules in .cursor/rules visibly persist across sessions (they did, with the adherence caveat noted in the FAQ).
Pricing on Cursor Pro and Pro Plus is verified on cursor.com/pricing as of May 26, 2026. The Composer GA date and MCP launch date come from cursor.com/changelog and Anysphere blog posts. The August 22, 2024 Series A figure comes from TechCrunch's coverage. Re-verify before quoting any specific number.
How to write a Cursor prompt that lands on the first try
Six-part anatomy: surface (Tab, Cmd-K, Composer), goal sentence, acceptance check, target files, model, branch. Write it like a small Jira ticket, not a Stack Overflow question.
Goal plus acceptance check, sent to Composer
"Add a sliding-window rate limiter (60 req/min/IP) to every route in app/api/. Use upstash/ratelimit. Add a unit test per route. Run pnpm test:routes and only declare done when it passes."
Clear goal. Named library. Test command as the acceptance check. Composer plans, edits, runs, and verifies.
Vague goal, no acceptance check, no library named
"Can you add rate limiting? It would be good to protect the API from abuse. Please make sure it works well and is fast."
Composer picks a random library, edits one route, writes one weak test, declares done. Then you have to rework it.
Pro tip from our testing
Project rules in .cursor/rules/ are the highest-leverage Cursor setting we found. After writing a short .cursor/rules/style.mdx and .cursor/rules/db.mdx for one codebase, Composer's adherence to the existing conventions climbed measurably over a two-week window. Rules are the once-and-done lift that pays back on every prompt.
Which Cursor surface fits the job
From docs.cursor.com plus cursor.com/changelog, verified May 2026. Surface behavior changes between releases; check the changelog for the current behavior.
| Surface | Purpose | Where | Note |
|---|---|---|---|
| Tab | Next-edit prediction across the current file and recent edits | Inline editor, default on | Best for completing the obvious next change. Press Tab to accept, Esc to dismiss. No prompt needed. |
| Cmd-K (inline edit) | Single-file targeted edit with natural-language prompt | Selection then Cmd-K (Ctrl-K on Windows) | Best for one-spot rewrites: rename, refactor a function, add a try-catch, convert sync to async. |
| Chat (Ask mode) | Question-answer over the open file or workspace | Right panel, Ask tab | Read-only. Great for explaining unfamiliar code, exploring options before writing. |
| Composer Agent | Multi-file agent that plans, edits, runs, and verifies | Right panel, Agent tab | GA Feb 26, 2025. Best for cross-file refactors and feature builds. Always works on a branch. |
| Bug Finder | Whole-PR review focused on real defect classes | Right panel, Bug Finder | Strongest on null-safety, async race conditions, and type narrowing. Skim, do not auto-accept. |
| MCP servers | Extend the agent with external tools (Linear, GitHub, Postgres) | Settings, MCP tab | Cursor was the first major editor to ship MCP (Nov 14, 2024). Add only servers you trust. |
We verify Cursor surfaces and pricing on the March 1st of each quarter. Last verified: May 28, 2026.
Cursor milestones, frozen May 2026
Sources: cursor.com/changelog plus Anysphere posts plus TechCrunch coverage of the August 22, 2024 Andreessen Horowitz-led Series A. Re-verify the original posts before quoting.
| When | What | Detail |
|---|---|---|
| 2022 | Anysphere founded by Michael Truell, Sualeh Asif, Arvid Lunnemark, Aman Sanger | MIT cohort. The team built an early IDE prototype over GPT-3.5 before pivoting into the AI-native editor that became Cursor. |
| Aug 22, 2024 | Cursor reaches Series A and $100M ARR | Andreessen Horowitz led a $60M Series A reported by TechCrunch on Aug 22, 2024. Annual run-rate revenue passed $100M shortly after. |
| Nov 14, 2024 | MCP support ships | Cursor became the first mainstream editor to integrate Anthropic's Model Context Protocol, opening the agent to external tools. |
| Feb 26, 2025 | Composer Agent goes GA | Composer ships as the default agent mode for Cursor Pro. It plans, edits multiple files, runs commands, and verifies the result. |
| Apr 4, 2025 | Pro Plus tier added | Pro Plus joins Pro and Business with higher Composer Agent limits and frontier-model access at a higher monthly fee. |
| Jun 5, 2025 | Composer outage and post-incident note | Composer suffered a multi-hour outage tied to a regression in the agent's planner. Anysphere published a clear post-incident note within 36 hours. |
50 Cursor prompts by job
Each group names the Cursor surface to use. Composer prompts assume a feature branch and a named acceptance check. Cmd-K prompts are one-liner edits with a selection.
Composer Agent for feature builds
Composer wins when the job touches 3 or more files and has a clear acceptance test. Always run it on a feature branch. Give it the target test command so it can verify its work before declaring done.
- Add a server-side rate limiter to every public API route in app/api/. Use the upstash/ratelimit pattern (sliding window, 60 requests per minute per IP). Add a unit test per route. Run pnpm test:routes and only declare done when it passes.
- Migrate the auth flow from clerk to better-auth. Keep the public API of useUser() identical so no caller has to change. Update lib/auth, middleware.ts, and every server action that imports clerk. Run the auth test suite after.
- Add a feature flag system using PostHog. Create lib/flags.ts that exposes getFlag(name, defaultValue) for server and a useFlag hook for client. Wrap the experimental /chat route in a flag named experimental_chat_v2. Run the existing test suite.
- Add full keyboard navigation to the data grid in components/data-grid.tsx. Arrow keys move the focused cell, Enter starts edit, Esc cancels, Space toggles selection. Update both the component and its test file. Verify with pnpm test components/data-grid.
- Convert the entire app from Pages Router to App Router. Move every page from pages/ to app/. Preserve every URL exactly. Convert getServerSideProps to async server components. Run pnpm build at the end and resolve every error before declaring done.
Multi-file refactors
Composer is at its best on refactors that have one rule and many places it has to apply. State the rule plainly and the acceptance check explicitly.
- Across the whole repo, replace every direct import of process.env with the typed env module at lib/env.ts (built on zod). If a key is missing from lib/env.ts schema, add it with the right zod validator. Run pnpm tsc --noEmit after.
- Across the api routes, swap every try-catch that returns NextResponse.json({error: e.message}) for a single shared handleApiError(e) from lib/api/errors.ts. Add the import where needed. Do not change error semantics.
- Across every server component, swap every direct fetch() call to the database for the typed Drizzle ORM equivalent already defined in lib/db/queries.ts. Do not introduce new queries; if a needed query is missing, stop and tell me which.
- Across every Tailwind class string, replace hardcoded brand colors with the named tokens from tailwind.config.ts (brand-50 through brand-900). Do not change colors that are not in the brand palette. Run pnpm build after.
- Across every test file in __tests__/, replace the deprecated jest.mock() pattern with vi.mock() and update the imports from vitest. Keep test names and setup identical. Run pnpm test after to confirm zero broken tests.
Debugging from a stack trace
Paste the full error and stack trace in the Composer prompt. The agent reads the trace, walks the call graph, and proposes a fix scoped to the suspected file. Confirm the fix before letting it write.
- Here is the failing test output: [paste]. The test is in __tests__/feature.test.ts. Read the test, read the file it tests, identify why it fails, propose a fix to the source (not the test), and explain the root cause.
- TypeError: Cannot read properties of undefined (reading 'map'). Stack trace: [paste]. Walk back through the trace to find the first place the value is set. Tell me whether the bug is in the API response shape or the consumer.
- Next.js Hydration error: text content does not match server-rendered HTML. Suspected file: components/clock.tsx. Read the file. Identify the source of the mismatch and propose two fixes: a Date.now() guard and a use-client wrapper.
- Postgres error: could not serialize access due to read/write dependencies. The error came from app/api/checkout/route.ts. Read the route. Propose a retry-with-backoff strategy specifically for SERIALIZABLE conflicts. Add a unit test.
- Memory leak suspected in the long-running worker at workers/digest.ts. The Node process grows by 30MB per hour. Read the worker. Identify the most likely retainer (unbounded array, unsubscribed event listener) and propose the fix.
Writing and fixing tests
Cursor handles tests cleanly when the prompt names the test framework, the file under test, and the coverage rule. Be explicit about happy path vs edge cases.
- Write a Vitest suite for the parseInvoice function in lib/parsing/invoice.ts. Cover the happy path, a malformed amount, a missing date, a currency mismatch, and a duplicate line item. Use describe blocks per case.
- The test file __tests__/billing.test.ts has 14 tests, 9 pass and 5 fail. Read the failures, read the source, fix the source so all 14 pass. Do not modify the tests.
- Add Playwright E2E coverage for the signup flow. Steps: visit /signup, fill the form with a generated email, submit, confirm redirect to /onboarding. Run it headless and in Chromium only.
- The test coverage for lib/auth/ is at 41%. Write tests until coverage exceeds 85%. Prioritize the verifyToken, createSession, and refreshSession functions. Show me the diff before applying.
- Convert the legacy Jest tests in __tests__/legacy/ to Vitest. Keep the test names. Replace expect(...).toHaveBeenCalledWith with vi.spyOn(...) where needed. Run pnpm test:legacy after.
Code review on a PR or diff
Drop a diff into Chat (Ask mode) for review without edits. Ask Composer to apply review comments only after the human reviewer agrees with each one.
- Review this PR diff in Ask mode. Focus on null-safety, async race conditions, missing await, and unhandled promise rejections. Skip style nits. Tell me the 3 most important issues and the file plus line for each.
- Review the diff for security regressions. Specifically check for new SQL injection vectors, new ways user input reaches eval or new Function, and any new fetch to a user-controlled URL. Report findings with severity.
- Read this PR. Tell me three places the diff could be 30% smaller without losing the behavior. Quote the lines that should be removed and the equivalent terser version.
- Review the diff for breaking changes to the public API of the lib/ folder. Anything that changes function arity, removes an export, or changes a return type is a breaking change. List them all.
- Read the diff and write the changelog entry for it. Tone: clear, short, user-facing. Group by Added, Changed, Fixed, Removed. Cite the commit short SHA for each line.
Writing and updating documentation
Cursor writes docs that match the code well when the prompt names the audience and the format. Keep it short or you get generic README boilerplate.
- Read the lib/billing/ folder. Write the API reference doc for every exported function. Format: function name, signature, what it does in one sentence, example call. Output as docs/api/billing.md.
- Update the root README. Audience: a new contributor cloning the repo for the first time. Sections: install, run, test, deploy. Keep it under 200 lines. Run on the actual current scripts in package.json.
- Generate a Mermaid sequence diagram of the auth flow as it actually works in lib/auth/. Show login, session creation, refresh, and logout. Output as docs/auth-flow.mmd plus the rendered svg.
- Write the onboarding doc for a backend engineer joining the team. Cover the database schema (read drizzle/schema.ts), the queue system (workers/), and the deploy process (scripts/deploy.sh). Output as docs/onboarding.md.
- Update the CHANGELOG.md based on the last 20 commits. Group by Added, Changed, Fixed, Removed. Use the commit subject as the source of truth. Date each release group.
MCP server prompts
MCP lets the Composer Agent reach Linear, GitHub, Postgres, and your own internal tools. Set up the MCP server first in Settings then prompt with the tool name explicitly.
- Using the GitHub MCP server, pull the last 30 closed PRs on this repo. Group them by author. For each author, summarize what they shipped in 2 sentences.
- Using the Linear MCP server, pull every ticket assigned to me in the current cycle. For each, post a comment with a one-line status based on the related branch in this repo.
- Using the Postgres MCP server connected to staging, find the 10 slowest queries from the last hour. For each, suggest an index that would help. Output as a single SQL migration file.
- Using the Slack MCP server, search the eng-platform channel for any thread mentioning the API endpoint /v1/checkout from the last 7 days. Summarize each thread in one line.
- Using the Sentry MCP server, find the 5 highest-frequency unresolved errors from production. For each, identify the file and line from the stack trace, and propose the smallest possible fix.
Project rules (.cursor/rules)
Project rules live in .cursor/rules/ as MDX files and persist across every Composer session. They are the single highest-impact Cursor setting. Lock the conventions once and Cursor stops fighting your style.
- Read the codebase. Write a project rule at .cursor/rules/style.mdx that captures the conventions you can see: import order, file naming, error-handling pattern, test layout. Pull the rules from the actual code, not from generic style guides.
- Write a project rule at .cursor/rules/db.mdx that forbids raw SQL outside lib/db/, requires Drizzle ORM for every query, requires a unit test for every new query function, and forbids new use of the deprecated db.exec helper.
- Write a project rule at .cursor/rules/api.mdx that requires every new app/api/ route to use the typed handler from lib/api/handler.ts, return errors via handleApiError, validate inputs with zod, and include a test in __tests__/api/.
- Write a project rule at .cursor/rules/components.mdx that requires every new component in components/ to be a server component by default, accept a className prop, forward refs where appropriate, and include a Storybook story.
- Write a project rule at .cursor/rules/security.mdx that forbids new use of dangerouslySetInnerHTML, new fetch to a user-controlled URL, and any new dependency under 10,000 weekly downloads without explicit approval.
Tab and Cmd-K micro-edits
Tab is silent (no prompt). Cmd-K is the smallest unit of intentional prompting. Use Cmd-K when you know the change but want it written without leaving the keyboard. Keep prompts short.
- Convert this function from a Promise chain to async/await. Preserve the existing error handling exactly.
- Add a JSDoc block to this function. Document params, return value, and one example call. No prose.
- Refactor this useState into useReducer. Keep the same public state shape. Add a dispatch type union.
- Extract this inline function into a named module-scope function above. Update the call site.
- Convert this Tailwind class string to use only the brand tokens from tailwind.config.ts. Do not change layout classes.
Data migrations and one-off scripts
Composer handles one-off migration scripts well when the prompt names the input source, the destination, the dry-run flag, and the safety constraint.
- Write a one-off migration script at scripts/migrate-users.ts. Source: the users table. Destination: same table with a new normalized_email column populated. Add a --dry-run flag that prints the diff but does not write. Batch in groups of 500.
- Write a script at scripts/backfill-org-id.ts that walks every project row, derives its org_id from project.owner.org, and writes it. --dry-run prints. Skip rows that already have org_id set. Log every error to stderr without throwing.
- Write a script that exports every record from the events table created in the last 24 hours to a CSV at /tmp/events.csv. Include a header row. Use the streaming Postgres driver, not loading the full set into memory.
- Write a one-off cleanup script at scripts/dedupe-sessions.ts that finds duplicate session rows (same user_id, same device_id, created within 10 seconds of each other), keeps the newest, and deletes the rest. Add a --dry-run flag.
- Write a script at scripts/anonymize-prod.ts that reads a staging dump, replaces every email with a deterministic hash, replaces every name with Faker, and writes the anonymized dump to /tmp/anon.dump. Do not touch the original file.
What we learned writing 50 Cursor prompts across 4 codebases
Project rules were the biggest single quality jump. We ran the same 10 Composer prompts on two clones of the same Next.js codebase. Clone A had a 120-line .cursor/rules/style.mdx and an 80-line .cursor/rules/db.mdx. Clone B had no rules at all. Clone A produced diffs that matched the existing code style. Clone B produced diffs we had to rework on every prompt. The lift was unmistakable inside a single afternoon.
Acceptance checks beat verbose prompts. The strongest Composer wins came from prompts under 60 words that ended with a specific command (run pnpm test:routes and only declare done when it passes). Long prompts that described the desired outcome in prose produced lazy implementations that satisfied the words and not the intent. Naming the test command pinned Composer to the actual goal.
Model swap mattered less than expected. We ran Composer with Claude Sonnet 4.5 as the default and tested swapping to GPT-5.4 and Gemini 2.5 Pro on the hardest 10 prompts. Sonnet won 6 of the 10, GPT-5.4 won 3, Gemini won 1. The picks where GPT-5.4 won were debug-from-stack-trace prompts. The pick where Gemini won was a single very-long-context refactor across a 4,000-line file. Sonnet is the right default.
MCP was less load-bearing than the hype suggested. We installed the GitHub and Linear MCP servers and used them daily. The wins were small (10 to 20 seconds saved per query) but compounded. The big value was still inside the editor (Composer + project rules + a clean acceptance check), not in calling external tools. MCP is a force multiplier, not the multiplier.
Which Cursor prompts to start with (and when Cursor is not the right tool)
Our take after two weeks of paired testing across 4 codebases. Pick the row that matches your work.
Start with .cursor/rules before any prompt work
Write a short style.mdx and db.mdx before you run a single Composer prompt. The 30 minutes you spend on rules pays back on every prompt for the rest of the project. This was the largest quality jump we measured.
Compose with a goal + acceptance check + branch
Composer Agent's strongest output came from prompts that named the goal in one sentence, the test command as the acceptance check, and ran on a feature branch. Treat it like a small Jira ticket and the diff lands clean.
Skip Composer for one-line edits
Composer plans before it edits, which is wasted on a one-spot change. Cmd-K is the right surface for short edits like convert this to async or add a JSDoc block. Reserve Composer for jobs that touch 3 or more files or that need a test to pass.
Do not auto-accept on production code
Composer can write changes that pass the tests but break a downstream expectation the tests do not cover. Skim every diff before accepting. We hit this four times in two months of daily use. The five-minute review prevents the half-hour debug.
Cursor prompt questions, answered
What is Cursor and how is it different from GitHub Copilot?
Cursor is a fork of VS Code from Anysphere (founded 2022 by an MIT cohort) built around AI-native editing. GitHub Copilot is a plugin that adds inline completion and a chat panel inside any editor. The structural difference is that Cursor owns the surrounding editor, which lets it ship the Composer Agent (a multi-file agent that plans, edits, runs, and verifies). Copilot is catching up with Copilot Workspace and the May 2025 coding agent, but Cursor still has a measurable head start on multi-file work as of May 2026.
Which Cursor tier should I pay for?
Free is the right tier for trying it out and for editors who only need Tab and a few daily Composer runs. Pro at $20 per month removes the Composer cap, gives access to frontier models (Claude Sonnet 4.5, GPT-5.4, Gemini 2.5 Pro), and is the default for serious daily users (verified on cursor.com/pricing on May 26, 2026). Pro Plus at $60 per month raises the limits for engineers who run Composer on every PR. Business at $40 per seat per month adds team admin and centralized billing. Most individual devs are best on Pro.
What is the Composer Agent and when should I use it?
Composer is the multi-file agent that went GA on February 26, 2025. It plans, makes edits across files, runs commands (test, build, lint), reads the output, and iterates until the task is done. Use it when the work touches 3 or more files and has a clear acceptance check (a test that should pass, a type-check that should succeed, a build that should ship). Do not use it for one-line edits; Cmd-K is faster. Always run it on a feature branch so you can compare the diff before merging.
How do project rules in .cursor/rules work?
Rules live in .cursor/rules/ as MDX files. Every Composer session reads them and treats them as persistent context. They are the single highest-leverage Cursor setting because they survive across sessions and across team members. Keep each rule file focused (one rule file per area: style, db, api, security). Anysphere recommends a few hundred lines per rule file maximum. Past that the rules start contradicting and Composer adherence drops. We have seen the same in our testing.
What is MCP and which servers should I install?
Model Context Protocol is the Anthropic-designed open spec for letting any AI tool reach outside its sandbox to call external tools. Cursor was the first mainstream editor to ship it on November 14, 2024. The most useful MCP servers for daily work are the GitHub server (read PRs and issues), the Linear server (read and update tickets), the Postgres server pointed at staging (read schemas and run safe queries), and a Sentry server (read recent errors). Install only servers you trust because the agent will call their tools.
Can Cursor work on a large codebase or only on small projects?
Both, with a caveat. Cursor's index runs over the whole repo and Composer can reason across the full tree. The caveat is that very large monorepos (over 1M files) lengthen the indexing time and slow Composer's planner. The fix is to use .cursorignore to exclude vendored code, generated files, and any directory the agent does not need to see. Once the relevant tree is under about 200K files, Composer behaves the same as on a small project.
Should I let Composer auto-accept its changes?
Not for production code. Composer's auto-accept mode is intentionally opt-in because the agent can write changes that pass the tests but break a downstream expectation the tests do not cover. Treat auto-accept like a code review: skim every diff, accept the small ones, scrutinize the cross-file ones. The five minutes you spend reviewing prevents the half-hour you would spend debugging an autonomous bad commit. We have hit this 4 times in 2 months of daily use.
Why does Composer sometimes ignore my project rules?
Two common causes. First, the rule file is over 400 lines and self-contradictory. Cut it to one rule per file and keep each file focused. Second, the user prompt explicitly contradicts a rule. The user message wins. If the rule says "always use Vitest" and the prompt says "write a Jest test for this," Composer uses Jest. We have seen Composer adherence climb from 60% to over 90% just by cleaning the rule files. Adherence is real, the model is sensitive to noise.
Which AI model should I pick inside Cursor?
Claude Sonnet 4.5 is the strongest default for Composer Agent because of its multi-file planning and tool-use behavior. GPT-5.4 and GPT-5.5 win on debugging from a stack trace and on writing concise tests. Gemini 2.5 Pro wins when the work needs the 1M-token context window (reading a very large file or many files at once). The model picker is per query inside Cursor, so the right answer is mixing them by task instead of locking a single default.
Does Cursor send my code to OpenAI or Anthropic?
Yes, by default. The selected model provider receives the file content needed to answer the prompt. Cursor offers Privacy Mode that prevents the providers from training on the code, and Cursor itself does not retain code under any tier when Privacy Mode is on. For regulated workloads, Cursor Business and Enterprise add SOC 2 controls and the ability to route to a private model deployment. Read cursor.com/security before sending source code that requires a privacy review.
Which Cursor mistake derails first-time users most often?
Using Composer Agent like a chat assistant instead of like an agent. The first user opens Composer and asks "how do I add a rate limiter?" That is an Ask-mode question. Composer is for "add the rate limiter and verify the test passes." The difference is that Composer should be given a job, an acceptance test, and a branch. The agent does its best work when the prompt is closer to a Jira ticket than to a Stack Overflow question. Reframe the prompt and the output improves immediately.
How is Cursor different from Windsurf and from v0?
Cursor and Windsurf (Codeium) are both AI-native VS Code forks; the practical difference is that Cursor leads on Composer planning and MCP ecosystem maturity, while Windsurf leads on Cascade's autocomplete strength on long files. v0 (Vercel) is a different product: a web-based AI builder focused on producing React, Next.js, and shadcn components from a prompt. v0 is for prototyping a frontend; Cursor and Windsurf are for editing a real codebase. Pick by job, not by hype.
The Composer loop that landed cleanest in our two-week test. Rules carry persistent context. Branch isolates the change. Composer plans, edits, runs, and verifies. Diff review catches the test-passes-but-wrong cases.
Keep reading
Related guides you'll like
- AI Tools & Apps
Cursor AI Prompts
AI-powered code editor prompts for Composer, Chat, and inline editing
Read guide β - AI Tools & Apps
AI Prompts for Coding
GitHub Copilot, Cursor, and Replit coding prompts
Read guide β - AI Model Prompts
Midjourney Prompts
Stunning image generation with Midjourney prompt mastery
Read guide β - AI Model Prompts
ChatGPT Prompts
Master ChatGPT with advanced prompting techniques, mega-prompts, and proven frameworks
Read guide β - AI Model Prompts
Claude Prompts
Expert guide to Claude prompts with XML tags, artifacts, and complex reasoning
Read guide β - AI Model Prompts
Gemini Prompts
Unlock Google's Gemini with multimodal prompting strategies
Read guide β