40 Best Cursor AI Prompts (2026)

Get your bearings in this repo before we change anything. Use @Codebase.

Do this:
- Map the project: languages, frameworks, entry points, and how it's built, run, and tested.
- Summarize the architecture in a short paragraph plus a bullet list of the main modules.
- List the commands to build, run, lint, and test.
- Flag anything fragile or unusual I should know before we make changes.

Don't edit any files yet — just report back.

Use Ask mode. With @Codebase, answer this without editing anything:

Question: [where does X happen / how does Y flow through the system]?

Do this:
- Point me to the exact files and functions involved, with paths.
- Explain the flow in order, step by step.
- Note anything surprising or inconsistent you find along the way.

I'm attaching exactly the context you need — use only this, don't wander the repo.

@[path/to/file-a] @[path/to/file-b] #[path/to/related-file]

Task: [what I want done], matching the patterns in the files above.

Do this:
- Follow the conventions in the attached files.
- Ask me for any file you need that I haven't attached instead of guessing.

Before you write code, check the current API. Use @Docs [library] and @Web.

Task: I need to [use feature] with [library/version].

Do this:
- Confirm the current, non-deprecated way to do this from the docs.
- Show a minimal working example that matches our stack: [stack].
- Note any recent breaking change or gotcha from the version we're on.
- Cite the doc or page you relied on.

Using @Codebase, draft project rules for Cursor so I stop repeating myself.

Do this:
- Create a .cursor/rules/ directory with focused .mdc files (e.g. general, testing, and one per major area).
- For each file, set the right type (Always, Auto Attached with a glob, or Agent Requested) and a scoping glob.
- Capture our real conventions: language/version, formatting, folder layout, naming, how we write tests, and "don't touch unrelated files".
- Keep each rule short and specific — no vague advice.

Show me the files and where they go before creating them.

Agent mode. Implement this feature end to end. Plan before editing.

Feature: [what it does]. Acceptance: [how we'll know it works].
Files likely involved: [path/a], [path/b] — confirm and add any others you need.

Do this:
- Outline your plan and the file list before making changes.
- Match the existing patterns in the surrounding code.
- Add or update tests, then run them and fix any failures.
- Summarize what changed and why.

Only touch the files needed for this feature.

Scaffold a [component / endpoint] following our conventions.

Stack: [framework and version]. It should [responsibility]. It talks to [DB / API / module].
Match the pattern in @[path/to/a/sibling-file].

Do this:
- Create the file(s) at the right path with types, error handling, and a minimal test.
- Leave clearly marked TODOs where I need to fill in business logic.
- List the files you created and a one-line note on each.

Don't wire it into anything else yet.

Build this UI. [Attach the screenshot, or describe it below.]

What it is: [screen/component]. Layout: [describe]. States: [empty, loading, error].
Stack: [framework + styling]. Match @[path/to/existing-component] for style and structure.

Do this:
- Build a responsive, accessible component with sensible defaults.
- Handle the empty, loading, and error states.
- Use our existing design tokens/components, not new ad-hoc styles.
- Show me the component and where it lives.

Wire [component/page] to [the API endpoint]. Use @Docs [library] if needed.

Endpoint: [method + path]. Request: [shape]. Response: [shape].
Follow the data-fetching pattern in @[path/to/existing-fetch].

Do this:
- Add the call with proper loading and error handling.
- Type the request and response.
- Handle non-200s and network failures gracefully.
- Add a test that mocks the endpoint.

Add a [form name] form with validation.

Fields: [field: type/rules, ...]. Submit does: [action]. Stack: [form/validation lib].
Match the pattern in @[path/to/an/existing-form].

Do this:
- Build the form with client-side validation and clear inline error messages.
- Disable submit while invalid or in flight; show success and failure states.
- Type the values and the submit payload.
- Add tests for a valid submit and each validation rule.

Design the schema and queries for this feature. Use @Docs [ORM/DB] if relevant.

What we're storing: [entities and relationships]. DB: [Postgres / MySQL / SQLite].
Existing schema/migrations: @[path/to/schema].

Do this:
- Propose the tables/columns/indexes with reasoning; call out trade-offs.
- Write the migration in our existing style.
- Write the main query/queries this feature needs, formatted and explained.
- Warn me about NULLs, uniqueness, and performance concerns.

Agent mode. Build a small self-contained tool.

What it does: [describe]. Input: [source]. Output: [format]. Run as: [CLI / script / tiny web page].

Do this:
- Create it as a new file/folder at [path]; keep dependencies minimal.
- Handle empty input and error cases.
- Add a short usage note at the top and a smoke test.
- Run it once to confirm it works, then show me the output.

Plan this change before touching any code. Use @Codebase.

Goal: [what should be true when done].

Do this:
- Find every file involved and list them with a one-line reason each.
- Propose a step-by-step plan and the order of edits.
- Call out risks, unknowns, and anything you'd want to confirm with me.

Don't edit anything yet — wait for me to approve the plan.

Agent mode. Implement this change across the repo, plan first.

Goal: [what should be true when done]. Acceptance: [how we'll know].

Do this:
- Outline the plan and file list, then make the change following existing patterns.
- Add or update tests, run them, and fix failures until green.
- Show a summary of what changed and why.

Ask before anything destructive (deleting files, migrations, force-push).

Rename/migrate [old] to [new] everywhere it's used. Use @Codebase to find all usages.

Do this:
- List every file and reference that needs to change before editing.
- Make the change consistently across all of them, including imports, types, tests, and docs.
- Update any config or string references, not just code symbols.
- Run the build and tests afterward and fix anything that broke.

Report anything ambiguous instead of guessing.

Run this as a background agent task while I keep working.

Task: [self-contained chunk of work]. Acceptance: [how we'll know it's done].

Do this:
- Work through it independently, following our conventions and .cursor/rules.
- Add/update tests and run them until they pass.
- Keep the change scoped to [paths]; don't touch anything else.
- When done, summarize the change and flag anything that needs my decision.

Make this change with a strict scope.

Change: [what to do]. Allowed files: [path/a], [path/b] — these only.

Rules:
- Do not modify, reformat, or "clean up" any file outside the allowed list.
- If the change genuinely requires touching another file, stop and ask me first.
- No drive-by refactors, no import reordering elsewhere, no version bumps.

Show me the per-file diff when you're done.

Agent mode with auto-run. Make [change] and don't stop until the tests pass.

Do this:
- Make the change, then run [test command].
- Read the output, fix failures, and re-run — loop until everything is green.
- If a test looks wrong (not the code), stop and explain before changing it.
- When green, summarize what you changed and paste the final test output.

Diagnose and fix the current errors. Use @Lint Errors and @Terminal.

Context: I was trying to [what you were doing]. Expected: [X]. Actual: [Y].

Do this:
- Give the most likely root cause first, then alternates.
- Apply the exact fix and point to where it goes.
- Run the relevant command/test to confirm it's resolved.
- Suggest one change that would stop this class of error recurring.

A test is failing and I'm not sure if the test or the code is wrong.

Test: @[path/to/test]. Code under test: @[path/to/code].
Run [test command] and read the failure with @Terminal.

Do this:
- Tell me whether the bug is in the test or the code, and how you know.
- Apply the minimal fix.
- Re-run the test to confirm it passes and nothing else broke.

Reproduce this bug before fixing it. Use @Codebase to find the relevant code.

Report: "[paste the user's description]". Steps: [if known]. Expected vs actual: [both].

Do this:
- Write a failing test (or a repro script) that demonstrates the bug, and run it to confirm you see it.
- Only then trace to the root cause and apply the smallest safe fix.
- Re-run the test to prove it's fixed.

Report the root cause, the fix, and how you verified it.

Trace this bug across the codebase. Use @Codebase.

Symptom: [what's wrong]. Where it surfaces: @[path/to/file].

Do this:
- Follow the data/control flow from where the symptom appears back to its source.
- List each hop (file → function) so I can see the path.
- Identify the actual root cause, not just the symptom's location.
- Propose the fix and the smallest place to make it.

Fix this type/build error properly, not by suppressing it. Use @Terminal and @Lint Errors.

Error: [paste it if not already in context].

Do this:
- Explain what the error actually means here.
- Fix the underlying cause; don't reach for "any", @ts-ignore, or casts unless truly unavoidable — and justify it if you do.
- Run the build/typecheck to confirm it's clean.
- Flag any related spot the same issue might hide.

Refactor @[path/to/file] for readability without changing behavior.

Do this:
- Keep the exact same inputs and outputs.
- Improve naming, structure, and flow; remove obvious duplication.
- Run the existing tests to prove behavior is unchanged.
- List what you changed and why, and flag any latent bug you noticed.

Don't touch any other file.

Split the large function in @[path/to/file] into smaller, well-named pieces.

Do this:
- Extract logical units into named helpers with single responsibilities.
- Keep behavior identical; note any hidden coupling you find.
- Give each new function a one-line description of its job.
- Run the tests to confirm nothing changed behaviorally.

Find and remove duplication in these files. Use @Codebase to spot repeats.

Scope: @[path/a] @[path/b] (and closely related files).

Do this:
- Identify genuinely duplicated logic (not just superficially similar code).
- Extract it into one shared, well-named place; update all call sites.
- Keep behavior identical and run the tests.
- Don't over-abstract — if two things only look alike, leave them.

Add types to @[path/to/file] without changing behavior.

Target: [TypeScript / Python hints / etc.].

Do this:
- Add accurate types; avoid "any"/loose types unless truly necessary.
- Where a type reveals a possible bug, flag it instead of hiding it.
- Keep runtime behavior identical and run the typecheck and tests.
- List any inconsistency the types surfaced that I should check.

Migrate @[path/to/file] from [old library/version] to [new]. Check @Docs [new library] first.

Do this:
- Confirm the current API from the docs before editing.
- Rewrite using the new API, preserving behavior.
- List every changed call and what replaced it.
- Flag deprecations and breaking changes; run the build and tests.

If you're unsure about an API detail, check @Docs or ask — don't guess.

Write thorough unit tests for @[path/to/file] and run them.

Framework: [Jest / pytest / etc.].

Do this:
- Cover the happy path, edge cases, and error paths.
- Include boundaries I'd forget (empty, null, max, negative, unicode).
- Name each test after the behavior it verifies.
- Run the suite and fix any failures; paste the final passing output.

Tell me what I'm not testing. Code: @[path/to/code]. Tests: @[path/to/tests].

Do this:
- List the untested paths, branches, and edge cases, ranked by risk.
- Write tests for the top gaps and run them.
- Flag any code that looks untested because it's actually unreachable or dead.

Write an integration test for [flow], end to end. Use @Codebase to see how the pieces connect.

Flow: [start] → [steps] → [expected result].

Do this:
- Test the real integration between [components/modules], not each in isolation.
- Set up and tear down any needed state or fixtures.
- Assert on the observable outcome, not internal details.
- Run it and confirm it passes; note anything flaky and how you made it deterministic.

Generate test data and mocks for @[path/to/code].

Do this:
- Produce varied, realistic fixtures covering normal, edge, and invalid cases (empty, unicode, boundary numbers, missing optional fields).
- Mock [external dependency / API / DB] with responses for success and failure paths.
- Match the shapes in the real types/schema — @[path/to/types].
- Return them where our tests expect them, ready to run.

Act as a staff engineer reviewing my changes. Use @Git to read the diff.

What this change is meant to do: [intent].

Do this:
- List issues most severe first: correctness, security, edge cases, then style.
- Give the file/line and a concrete fix for each.
- Call out what I got right so I keep doing it.
- Don't rewrite whole files — point to specific lines.

Review my changes for security issues only. Use @Git for the diff.

Context: this code [handles user input / touches auth / calls external services].

Do this:
- Flag injection, auth/authorization gaps, unsafe deserialization, secrets in code, and XSS/CSRF/SSRF where relevant.
- Rate each finding (high/medium/low) with the attack it enables.
- Give the fix for each.
- Note anything you can't judge without seeing more of the system.

Write documentation for @[path/to/module or the project].

Audience: [teammates / external users / future me].

Do this:
- A short "what and why" overview.
- Usage examples that actually run.
- Parameters, return values, and errors in a table.
- Gotchas and assumptions a newcomer would trip on.

Match the tone of docs a good open-source project would ship.

Ask mode. Explain @[path/to/file] to me like I'll have to maintain it.

Do this:
- Give a plain-English summary of what it does and why it exists.
- Walk through it in execution order, calling out anything non-obvious.
- Explain how it connects to the rest of the system (@Codebase if needed).
- Flag anything that looks like a bug, a smell, or a risky assumption.

Don't change anything — just explain.

Write a commit message from my staged changes. Use @Git diff.

Do this:
- A conventional commit: subject under 72 chars, then a body explaining what and why.
- Group related changes; don't just list every file.
- Note any breaking change with a BREAKING CHANGE footer.

Base it on the actual diff, not assumptions.

Write a PR description for this branch. Use @Git to read all the changes.

Do this:
- Summary: what changed and why.
- How it was tested (and how a reviewer can verify).
- Risks, migrations, or follow-ups.
- A short reviewer checklist, and the one or two things to look at most closely.

Keep it tight and skimmable.

Update the changelog for this release. Use @Git for the changes since [last tag/version].

Do this:
- Group entries under Added / Changed / Fixed / Removed.
- Write each in user-facing language, not commit-speak.
- Call out breaking changes and any migration steps.
- Match the format already in @[path/to/CHANGELOG].

Help me resolve the merge conflicts in @[path/to/conflicted-file]. Use @Git for context on both sides.

Do this:
- For each conflict, explain what each side was trying to do.
- Propose a resolution that preserves both intents where possible — don't just pick one blindly.
- Flag any conflict where the correct choice isn't obvious and ask me.
- After resolving, run the build and tests to confirm nothing broke.