Best Cursor Prompts for Building Apps and Working With Codebases in 2026

Cursor can do much more than generate individual lines of code.

Its coding agent can explore a repository, locate relevant files, modify multiple parts of a project, run terminal commands, execute tests, review changes, and help carry a feature from planning to implementation.

However, giving Cursor access to an entire codebase does not automatically mean it understands what you want.

Prompts such as:

• Fix this feature.
• Make the app better.
• Refactor the backend.
• Add authentication.
• Build the entire dashboard.

leave Cursor with too many decisions to make.

The agent still needs to determine which files matter, which existing patterns should be reused, what behavior must remain unchanged, which requirements are essential, and how the result should be verified.

A strong Cursor prompt gives the agent enough direction to explore the codebase intelligently without giving it unlimited freedom.

It explains the goal, relevant product context, expected behavior, scope, constraints, acceptance criteria, and validation requirements.

This guide contains reusable Cursor prompts for understanding codebases, planning features, editing multiple files, debugging issues, refactoring safely, writing tests, reviewing diffs, creating project rules, working from the terminal, and building applications more reliably.

Quick Answer

The best Cursor prompts clearly define the task, codebase context, expected behavior, constraints, acceptance criteria, and verification process.

For complex changes, use a structured workflow:

1. Ask Cursor to inspect the codebase without editing files.
2. Identify relevant files, symbols, dependencies, and existing patterns.
3. Create an implementation plan before coding.
4. Review and correct the plan.
5. Implement one logical unit at a time.
6. Run the relevant tests and validation commands.
7. Review the final diff for accidental or incomplete changes.
8. Store repeated instructions in Cursor Rules or AGENTS.md.

The objective is not to write the longest possible prompt. The objective is to give Cursor enough context and clear completion criteria to make useful decisions with fewer assumptions.

Key Takeaways

• Use read-only exploration before allowing broad changes to an unfamiliar codebase.
• Plan complex features before implementation.
• Let Cursor search for context when you do not know the relevant files.
• Reference exact files or symbols when they are important to the task.
• Define what Cursor may change and what it must preserve.
• Break large requests into smaller, independently verifiable tasks.
• Require tests, type checking, linting, and build validation when relevant.
• Start a new conversation when moving to a different feature or task.
• Use Project Rules for persistent and scoped codebase instructions.
• Use reusable commands for workflows you perform repeatedly.
• Review AI-generated diffs before accepting or merging them.

Table of Contents

• What Are Cursor Prompts?
• Cursor Prompts vs. General AI Coding Prompts
• Choosing the Right Cursor Mode
• How Context Works in Cursor
• Cursor Prompt Structure
• How to Write Better Cursor Prompts
• Best Cursor Prompts
• Cursor Rules and AGENTS.md
• Reusable Cursor Commands
• Cursor CLI Prompts
• Weak vs. Strong Cursor Prompts
• A Reliable Cursor Workflow
• Common Cursor Prompting Mistakes
• Using PrompTessor for Cursor Prompts
• Cursor Prompt Checklist
• Official Cursor Resources
• FAQ

What Are Cursor Prompts?

Cursor prompts are natural-language instructions given to Cursor's AI features to understand, explain, create, modify, test, or review software.

A Cursor prompt may ask the agent to:

• Explain how an unfamiliar codebase works.
• Locate the implementation of a specific workflow.
• Plan a feature before editing files.
• Implement a multi-file change.
• Investigate a bug using repository and runtime context.
• Refactor code while preserving behavior.
• Generate and run tests.
• Review the current branch or diff.
• Create persistent project instructions.
• Automate a repeated development workflow.

Unlike a prompt sent to a general chatbot, a Cursor prompt can operate inside the development environment.

Depending on the selected mode and permissions, Cursor may search files, inspect definitions, view Git changes, edit code, run terminal commands, and use configured external tools.

This means that a Cursor prompt should explain not only what answer you want, but also how the agent should work inside the project.

Cursor Prompts vs. General AI Coding Prompts

General AI coding prompts often contain the code directly:

Review this function and identify potential bugs.

[PASTE FUNCTION]

Cursor prompts can instead ask the agent to locate the relevant code inside a repository:

Inspect the current authentication flow and identify where sessions are created, validated, refreshed, and revoked.

Do not modify files yet.

Return the relevant file paths, symbols, data flow, and any security-sensitive boundaries.

The main difference is codebase access.

A strong Cursor prompt may rely on the agent to search the repository, but it should still define:

• The product or technical goal.
• The area of the codebase to investigate.
• The expected user or system behavior.
• The scope of allowed changes.
• Important constraints.
• The required evidence of completion.

For model-independent templates covering individual tasks such as debugging, testing, API development, databases, performance, and security, see the guide to AI coding prompts for software development.

For a broader workflow that begins with a product idea and continues through MVP planning, implementation, refinement, and launch, see the guide to vibe coding prompts.

Choosing the Right Cursor Mode

The same prompt can behave differently depending on which Cursor mode you use.

Ask Mode

Ask Mode is useful when you want Cursor to explore and explain the codebase without making automatic changes.

Use it for:

• Understanding an unfamiliar repository.
• Finding where a feature is implemented.
• Tracing data flow.
• Comparing architectural approaches.
• Identifying relevant files before implementation.

A useful opening instruction is:

Do not modify any files.

Inspect the codebase and explain how this workflow currently works.

Plan Mode

For complex work, planning before coding helps expose missing requirements and incorrect assumptions.

Use Plan Mode when available in your Cursor release, or explicitly instruct the agent not to edit files while planning.

A planning request should ask Cursor to:

• Research the existing implementation.
• Identify relevant files and symbols.
• Ask focused clarification questions.
• Propose a step-by-step implementation plan.
• Wait for approval before changing code.

Agent Mode

Agent Mode is intended for more autonomous development work, including codebase exploration, multi-file edits, terminal commands, and error correction.

Use it after the task and implementation plan are sufficiently clear.

Manual or Targeted Editing

Use a targeted editing workflow when you already know exactly which files should change and do not need broad repository exploration.

This is useful for small, contained edits such as:

• Updating a label.
• Changing a validation message.
• Modifying a known component.
• Applying a small type correction.

Custom Modes

Custom modes can be useful for specialized workflows that require a particular set of tools and instructions.

Possible examples include:

• Read-only architecture review.
• Security-focused review.
• Test generation.
• Documentation updates.
• Strict refactoring without feature changes.

How Context Works in Cursor

Cursor can search the repository to locate relevant code, so you do not need to manually attach every possible file.

Adding too much unrelated context can make the actual task less clear.

Use explicit context when a file, folder, symbol, rule, document, or previous conversation is directly relevant.

Useful Context References

• @Files for specific files.
• @Folders for a relevant directory or module.
• @Code for a specific symbol or code section.
• @Docs for product or framework documentation.
• @Git for repository history and changes.
• @Past Chats for decisions from earlier Cursor conversations.
• @Cursor Rules for project-specific instructions.
• @Web for external sources when current information is required.

When to Attach Files Explicitly

Attach exact files when:

• You know the task is limited to those files.
• A file contains the canonical pattern Cursor should follow.
• The agent previously selected the wrong implementation.
• The relevant code has ambiguous names.
• You need to compare two specific implementations.

When to Let Cursor Search

Let the agent search when:

• You do not know where the feature is implemented.
• The workflow crosses multiple modules.
• You need to understand dependencies before editing.
• The repository has established patterns the agent should discover.

Cursor Prompt Structure

A reliable Cursor prompt can include the following components.

1. Mode or Working Approach

Tell Cursor whether it should explore, plan, implement, or review.

Use a read-only approach first.

Do not modify files until you have explained the current implementation and proposed a plan.

2. Task or Desired Outcome

State the specific result you need.

Task:
Add workspace-level role permissions to the existing project management application.

3. Product Context

Explain why the change is needed and who it affects.

Product context:
Workspace owners need to invite members without giving every member permission to change billing or workspace settings.

4. Relevant Codebase Context

Reference known files or ask Cursor to locate the implementation.

Known context:
- Authentication already exists.
- Workspace membership is stored in the database.
- Locate the current workspace authorization checks before proposing changes.
- Reuse existing validation and error-response patterns.

5. Current Behavior

Describe what currently happens.

Current behavior:
Every workspace member can access the settings routes after authentication.

6. Expected Behavior

Describe the desired result.

Expected behavior:
Owners can access all workspace settings.
Admins can manage members but cannot access billing.
Members can access projects but cannot change workspace settings.

7. Scope and Non-Goals

Define what Cursor may and may not change.

Scope:
- Add owner, admin, and member roles.
- Enforce permissions on the server.
- Update the relevant interface states.

Non-goals:
- Do not replace the authentication provider.
- Do not redesign unrelated dashboard pages.
- Do not add custom roles in this task.

8. Technical Constraints

Specify compatibility and architectural requirements.

Constraints:
- Preserve current API response formats.
- Reuse the existing authorization utilities.
- Avoid introducing a new dependency.
- Maintain compatibility with existing workspace records.
- Include a safe migration strategy.

9. Acceptance Criteria

Define observable completion conditions.

Acceptance criteria:
- Owners retain full access.
- Admins can invite and remove members.
- Admins cannot access billing settings.
- Members cannot access workspace administration routes.
- Unauthorized API requests return the existing forbidden response format.
- Existing users are migrated safely.
- Relevant tests pass.

10. Verification Requirements

Tell Cursor which commands or checks to perform.

Verification:
- Add tests for each role.
- Run the affected unit and integration tests.
- Run type checking.
- Run linting.
- Run the production build.
- Report any check that cannot be completed.

11. Response Format

Specify how Cursor should report its work.

Before implementation:
1. Explain the current authorization flow.
2. List relevant files and symbols.
3. Identify migration and compatibility risks.
4. Propose an implementation plan.
5. Wait for approval.

After implementation:
1. Summarize the changes.
2. List modified files.
3. Report validation performed.
4. Confirm each acceptance criterion.
5. Explain remaining risks.

How to Write Better Cursor Prompts

Start With Exploration for Unfamiliar Code

Do not ask Cursor to immediately change an implementation you do not yet understand.

Start with:

Do not modify files.

Trace this workflow through the codebase and explain the current behavior, relevant files, important symbols, data flow, and existing tests.

Ask for a Plan Before Broad Changes

For multi-file changes, request a reviewable plan first.

Create an implementation plan before writing code.

Include affected files, data changes, compatibility concerns, tests, and possible risks.

Wait for approval before implementation.

Use Product Behavior, Not Only Technical Tasks

Weak:

Add a role column.

Stronger:

Add workspace roles so owners can manage billing, admins can manage members, and regular members can access projects without administrative permissions.

Tell Cursor What to Preserve

Explicitly list existing behavior that must not change.

Preserve:
- Existing public API contracts
- Current session behavior
- Existing database identifiers
- Current analytics events
- Mobile layout
- Backward compatibility with stored user data

Give Cursor Verifiable Goals

Statements such as “make it work” do not define success.

Use concrete conditions:

The task is complete when:

- An owner can invite a member.
- The invited member can accept the invitation.
- The member cannot access billing.
- Invalid invitations display a clear error.
- Relevant tests and the production build pass.

Keep Each Conversation Focused

Continue the current conversation while iterating on the same feature.

Start a new conversation when:

• You move to a different feature.
• The previous task is complete.
• The agent repeatedly misunderstands the request.
• The conversation has accumulated unrelated context.

Use @Past Chats to bring important decisions into the new conversation without copying the entire history.

Best Cursor Prompts

1. Explore an Unfamiliar Codebase

Use this prompt in Ask Mode or another read-only workflow.

Help me understand this codebase before I make any changes.

Do not modify files or run destructive commands.

First inspect:

- Repository structure
- Application entry points
- Main modules
- Data-access layer
- API or server boundaries
- Authentication and authorization
- Shared components and utilities
- Testing structure
- Build and deployment configuration

Return:

1. A high-level architecture summary
2. The purpose of each major directory
3. The primary application workflows
4. Important files and symbols
5. How data moves through the system
6. Existing architectural patterns
7. Commands used for development, testing, and building
8. Areas that appear incomplete, duplicated, or risky
9. Questions I should answer before changing the project

Reference specific file paths and symbols for every important explanation.

2. Trace a Feature Through the Repository

Trace the complete implementation of the following feature through this repository.

Feature:
[DESCRIBE THE FEATURE]

Do not modify files.

Identify:

- User interface entry point
- Client-side state
- Form validation
- API or server handler
- Authentication check
- Authorization check
- Business logic
- Database operations
- External services
- Error handling
- Analytics or logging
- Unit, integration, and end-to-end tests

Return:

1. The workflow in execution order
2. Relevant file paths and symbols
3. Inputs and outputs at every stage
4. Important assumptions
5. Edge cases already handled
6. Edge cases that appear missing
7. Potential security or data-integrity boundaries
8. A Mermaid diagram of the workflow

Separate confirmed behavior from anything you are inferring.

3. Plan a Feature Before Editing

Plan the following feature for this existing codebase.

Feature:
[DESCRIBE THE FEATURE]

User value:
[WHY THE FEATURE IS NEEDED]

Current behavior:
[DESCRIBE CURRENT BEHAVIOR]

Expected behavior:
[DESCRIBE EXPECTED BEHAVIOR]

Requirements:
[LIST REQUIREMENTS]

Constraints:
[LIST CONSTRAINTS]

Non-goals:
[LIST WHAT IS OUT OF SCOPE]

Do not modify any files yet.

First:

1. Inspect the existing implementation.
2. Locate similar features and canonical patterns.
3. Identify affected files, symbols, routes, and data models.
4. Identify missing requirements or conflicts.
5. Ask focused clarification questions.
6. Propose the smallest maintainable implementation.
7. Explain database, API, interface, and testing changes.
8. Identify migration and backward-compatibility risks.
9. Divide the work into independently verifiable steps.
10. Define acceptance criteria for each step.

Return a detailed implementation plan with file paths and wait for approval before coding.

4. Build a Feature in an Existing Codebase

Implement the approved feature in this existing repository.

Feature:
[FEATURE]

Approved plan:
[PASTE OR REFERENCE THE PLAN]

Expected user workflow:
[WORKFLOW]

Relevant requirements:
[REQUIREMENTS]

Constraints:
[CONSTRAINTS]

Acceptance criteria:
[ACCEPTANCE CRITERIA]

Follow these rules:

- Inspect each relevant file before editing.
- Follow existing architectural and naming patterns.
- Reuse existing components, utilities, and validation.
- Avoid unrelated refactoring.
- Do not replace existing dependencies without approval.
- Preserve public APIs and stored data unless the plan explicitly changes them.
- Handle loading, empty, success, and error states.
- Enforce authentication and authorization on the server.
- Add or update relevant tests.
- Do not hide unfinished functionality behind placeholders.

After implementation:

1. Summarize the user-visible behavior.
2. List every modified file and its purpose.
3. Explain important implementation decisions.
4. Report tests and commands executed.
5. Confirm each acceptance criterion.
6. Identify remaining assumptions, limitations, or risks.
7. Review the final diff for accidental changes.

5. Make a Controlled Multi-File Change

Apply the following change across the codebase.

Change:
[DESCRIBE THE CHANGE]

Reason:
[WHY IT IS NEEDED]

Affected area:
[MODULE, FEATURE, OR DIRECTORY]

Behavior that must remain unchanged:
[LIST EXISTING BEHAVIOR]

Technical constraints:
[LIST CONSTRAINTS]

Before editing:

1. Find every relevant usage.
2. Identify public interfaces and dependent modules.
3. Identify generated files that should not be edited manually.
4. Identify tests that protect the existing behavior.
5. Explain the safest sequence of changes.

During implementation:

- Change one logical layer at a time.
- Preserve backward compatibility where required.
- Avoid formatting unrelated files.
- Avoid broad renaming outside the defined scope.
- Update types, documentation, and tests where required.
- Stop and explain if the requested change conflicts with the existing architecture.

After implementation:

- List all changed usages.
- Report tests and validation.
- Identify any references that could not be updated confidently.
- Review the final diff for unrelated modifications.

6. Debug a Reproducible Issue

Investigate the following bug using evidence from the codebase and runtime behavior.

Bug:
[DESCRIBE THE BUG]

Current behavior:
[WHAT HAPPENS]

Expected behavior:
[WHAT SHOULD HAPPEN]

Steps to reproduce:
1. [STEP]
2. [STEP]
3. [STEP]

Environment:
[BROWSER, OPERATING SYSTEM, RUNTIME, DEPLOYMENT, ETC.]

Observed error:
[ERROR MESSAGE, LOG, OR STACK TRACE]

Do not immediately guess a fix.

Follow this process:

1. Trace the relevant execution path.
2. Identify the files and symbols involved.
3. Generate several plausible root-cause hypotheses.
4. Compare each hypothesis with the available evidence.
5. Add temporary, safe instrumentation if runtime evidence is insufficient.
6. Ask me to reproduce the issue when additional data is required.
7. Identify the most likely root cause.
8. Propose the smallest safe correction.
9. Add a regression test when practical.
10. Remove temporary instrumentation after verification.

Do not:

- Suppress the error
- Disable validation
- Weaken types without justification
- Modify unrelated code
- Claim the issue is fixed without verification

Return:

- Root cause
- Supporting evidence
- Fix
- Modified files
- Regression coverage
- Validation performed
- Remaining uncertainty

7. Refactor Without Changing Behavior

Refactor the following area without changing its observable behavior.

Target:
[FILES, COMPONENT, MODULE, OR SYMBOL]

Reason:
[DUPLICATION, COMPLEXITY, MAINTAINABILITY, ETC.]

Current concerns:
[DESCRIBE CONCERNS]

Constraints:
[LIST CONSTRAINTS]

Before editing:

1. Explain the current responsibilities and data flow.
2. Identify public interfaces and dependent code.
3. Identify tests that protect existing behavior.
4. Find duplicated logic and unclear responsibility boundaries.
5. Propose a small sequence of refactoring steps.
6. Identify any behavior that is not sufficiently covered.

During implementation:

- Separate refactoring from feature changes.
- Preserve public interfaces unless explicitly approved.
- Avoid broad rewrites.
- Add characterization tests when existing behavior is unclear.
- Run relevant tests after every meaningful step.
- Stop if preserving behavior cannot be verified.

Afterward:

- Summarize the structural improvements.
- Explain which behavior was preserved.
- List modified files.
- Report tests and checks.
- Identify remaining technical debt.
- Identify any behavior that still requires manual verification.

8. Use Test-Driven Development

Implement the following behavior using a test-driven development workflow.

Behavior:
[DESCRIBE EXPECTED BEHAVIOR]

Input and output examples:
[ADD EXAMPLES]

Edge cases:
[LIST EDGE CASES]

Testing framework:
[FRAMEWORK]

Relevant existing tests:
[FILES OR ASK CURSOR TO LOCATE THEM]

Phase 1: Tests

- Inspect existing test conventions.
- Write tests for the expected public behavior.
- Include meaningful success and failure cases.
- Avoid testing private implementation details.
- Do not write implementation code yet.
- Run the tests and confirm the new tests fail for the expected reason.

Stop after Phase 1 and report the failing tests.

Phase 2: Implementation

After approval:

- Implement the smallest change that satisfies the tests.
- Do not weaken or remove the approved tests.
- Follow existing project patterns.
- Keep iterating until the relevant tests pass.
- Run type checking, linting, and the production build when relevant.

Final report:

- Tests added
- Initial failure reason
- Implementation summary
- Modified files
- Final test results
- Remaining coverage gaps

9. Implement a UI From a Screenshot

Implement the attached interface inside this existing application.

Use the screenshot as visual reference, not as permission to replace the existing design system.

Before editing:

1. Inspect the current layout and reusable components.
2. Identify existing typography, spacing, color, border, and responsive patterns.
3. Identify which components can be reused.
4. Identify missing interaction details that cannot be inferred from the screenshot.
5. Propose the component structure.

Requirements:
[LIST FUNCTIONAL REQUIREMENTS]

Responsive requirements:
[DESKTOP, TABLET, AND MOBILE EXPECTATIONS]

States:
- Loading
- Empty
- Success
- Error
- Disabled
- Hover and focus where relevant

Constraints:
- Preserve existing navigation and functionality.
- Use semantic HTML.
- Maintain keyboard accessibility.
- Do not introduce a new component library.
- Do not use hardcoded production data.
- Avoid unrelated redesigns.

After implementation:

- Compare the result with the reference.
- Use available browser tools to verify the layout.
- Report responsive and accessibility considerations.
- List components reused or created.
- Identify visual differences that remain.

10. Review the Current Diff

Review the current Git changes as a senior software engineer.

Do not modify files during the first review.

First inspect:

- Staged changes
- Unstaged changes
- Relevant surrounding code
- Existing tests
- Public interfaces affected by the changes

Review for:

- Incorrect behavior
- Missing requirements
- Edge cases
- Authentication and authorization
- Input validation
- Data integrity
- Error handling
- Security risks
- Performance regressions
- Race conditions
- Backward compatibility
- Unnecessary complexity
- Duplicate logic
- Missing interface states
- Accessibility
- Test quality
- Accidental or unrelated changes

For every issue, provide:

- Severity: critical, high, medium, or low
- File and location
- Explanation
- User or system impact
- Recommended correction
- Suggested verification

Also provide:

- What was implemented well
- Missing tests
- Assumptions that need confirmation
- Risks requiring manual review
- Overall merge-readiness verdict

Separate confirmed issues from possible concerns.

11. Continue Work From a Previous Cursor Conversation

Continue the same feature using the relevant context from @Past Chats and the current Git changes.

Before editing:

1. Summarize the previous objective.
2. Summarize decisions that were already approved.
3. Identify what has been implemented.
4. Identify unfinished steps.
5. Compare the current repository state with the previous plan.
6. Identify any conflicts between the past conversation and current code.
7. Confirm the next logical task.

Do not repeat completed work.

Current objective:
[DESCRIBE THE NEXT STEP]

Constraints:
[LIST CONSTRAINTS]

Return:

- Previous decisions
- Current implementation state
- Remaining work
- Relevant files
- Recommended next action
- Questions requiring clarification

Wait for confirmation if the current state differs meaningfully from the previous plan.

12. Create a Cursor Project Rule

Create a focused Cursor Project Rule for the following repeated project requirement.

Requirement:
[DESCRIBE THE REPEATED INSTRUCTION]

Relevant area:
[PROJECT-WIDE OR FILE PATTERN]

Canonical examples:
[REFERENCE EXISTING FILES]

The rule should:

- Be concise and actionable.
- Describe behavior Cursor can follow consistently.
- Reference canonical files instead of copying large code examples.
- Include only instructions relevant to the specified scope.
- Avoid duplicating linting or formatting configuration.
- Avoid documenting rare edge cases.
- Use the correct rule metadata and scope.
- Explain when the rule should be applied.

Return:

1. Recommended filename inside .cursor/rules/
2. Rule type
3. Globs or scope
4. Complete MDC content
5. Explanation of why each instruction belongs in the rule
6. Instructions that should remain in normal documentation instead

Do not modify other rules unless necessary.

13. Create an AGENTS.md File

Create a concise AGENTS.md file for this repository.

First inspect:

- Project structure
- Package scripts
- Current architecture
- Code conventions
- Testing tools
- Existing documentation
- Existing Cursor Rules
- Canonical implementation examples

Include only stable instructions that should apply across the project:

- Product purpose
- Technical stack
- Important architecture rules
- Directory responsibilities
- Coding conventions not already enforced automatically
- Authentication and authorization requirements
- Database migration practices
- Required validation commands
- Files or systems that should not be modified manually
- Expected reporting after completing a task

Avoid:

- Copying the entire README
- Repeating linter rules
- Documenting temporary implementation details
- Adding assumptions not supported by the repository
- Writing vague instructions such as "write clean code"

Return the complete AGENTS.md content and list any project decisions that require confirmation.

14. Create a Reusable Cursor Command

Create a reusable Cursor command for the following repeated workflow.

Command:
[EXAMPLE: /prepare-pr]

Workflow goal:
[DESCRIBE THE OUTCOME]

Required steps:
[LIST REQUIRED STEPS]

Constraints:
[LIST SAFETY OR PROJECT CONSTRAINTS]

The command should:

- Inspect the current Git changes.
- Avoid including unrelated files.
- Run the required project validation.
- Stop when validation fails.
- Summarize important changes.
- Generate a clear output.
- Avoid destructive Git operations.
- Ask for approval before pushing or opening external resources when appropriate.

Return:

1. Recommended filename inside .cursor/commands/
2. Complete Markdown command content
3. Required tools or dependencies
4. Safety considerations
5. Example invocation
6. Expected output

15. Prepare a Pull Request

Prepare the current branch for a pull request.

Before making any Git changes:

1. Inspect staged and unstaged changes.
2. Identify unrelated or suspicious modifications.
3. Review the diff against the target branch.
4. Run the required tests, type checking, linting, and build.
5. Stop if required validation fails.

Then provide:

- Summary of the change
- User-visible behavior
- Technical implementation
- Modified areas
- Tests performed
- Migration or configuration requirements
- Known limitations
- Screenshots or verification artifacts required
- Suggested commit message
- Suggested pull request title
- Suggested pull request description

Do not push, force-push, or open the pull request until I approve the summary.

16. Cursor CLI Code Review Prompt

This prompt can be used in an interactive Cursor CLI session or in a non-interactive review workflow.

Review the current repository changes without modifying files.

Compare the current branch with the main branch.

Identify:

- Functional bugs
- Security concerns
- Missing validation
- Backward-compatibility risks
- Unintended file changes
- Missing tests
- Incomplete documentation
- Configuration or migration requirements

Return a structured report with:

- Severity
- File and location
- Evidence
- Impact
- Recommended correction
- Verification method
- Overall merge-readiness verdict

Example CLI invocation:

agent -p "Review the current repository changes without modifying files. Compare the current branch with main and return a structured report of correctness, security, compatibility, and testing issues." --output-format text

If your installation still exposes the backward-compatible executable name, use cursor-agent instead of agent.

17. Complete Cursor Master Prompt

You are working as a careful senior software engineer inside an existing repository.

Task:
[DESCRIBE THE TASK]

Product context:
[DESCRIBE WHY THE TASK MATTERS]

Current behavior:
[DESCRIBE CURRENT BEHAVIOR]

Expected behavior:
[DESCRIBE EXPECTED BEHAVIOR]

Known relevant files:
[REFERENCE FILES OR ASK CURSOR TO LOCATE THEM]

Requirements:
[LIST REQUIREMENTS]

Constraints:
[LIST WHAT MUST BE PRESERVED]

Non-goals:
[LIST WHAT IS OUT OF SCOPE]

Acceptance criteria:
[LIST OBSERVABLE COMPLETION CONDITIONS]

Required validation:
[TESTS, TYPE CHECKING, LINTING, BUILD, MANUAL VERIFICATION]

Follow this process:

Phase 1: Explore

- Do not modify files.
- Inspect the relevant codebase.
- Explain the current implementation.
- Identify relevant files, symbols, dependencies, and tests.
- Separate confirmed behavior from assumptions.

Phase 2: Clarify

- Identify missing requirements and conflicts.
- Ask focused questions when an important decision cannot be inferred safely.
- Identify security, compatibility, migration, and data-integrity risks.

Phase 3: Plan

- Propose the smallest maintainable solution.
- List every file expected to change and why.
- Explain data, API, interface, and testing changes.
- Divide broad work into independently verifiable steps.
- Wait for approval before major changes.

Phase 4: Implement

- Follow existing project conventions and Cursor Rules.
- Reuse existing components, utilities, and patterns.
- Avoid unrelated refactoring.
- Preserve public behavior outside the approved scope.
- Handle loading, empty, success, and error states when relevant.
- Add server-side validation and authorization where required.
- Add or update relevant tests.

Phase 5: Verify

- Run the required tests and checks.
- Investigate failures instead of ignoring them.
- Confirm every acceptance criterion.
- Review the final diff for accidental changes.
- Do not claim a check passed if it was not performed.

Phase 6: Report

Return:

- Summary of changes
- User-visible behavior
- Modified files
- Important implementation decisions
- Tests and commands executed
- Acceptance criteria results
- Assumptions
- Known limitations
- Remaining risks
- Recommended follow-up work

Cursor Rules and AGENTS.md

Repeatedly adding the same project instructions to every prompt wastes context and creates inconsistency.

Cursor provides persistent instruction systems for reusable project guidance.

Project Rules

Project Rules are stored inside:

.cursor/rules/

They are appropriate for instructions that should be version-controlled and scoped to a project, directory, or file pattern.

Examples include:

• Where API routes belong.
• How authorization must be enforced.
• Which component pattern is canonical.
• Which commands must run after changes.
• How database migrations should be handled.
• Which generated files must not be edited.

Example rule:

---
description: Standards for API route implementation
globs:
  - "app/api/**/*.ts"
alwaysApply: false
---

# API Route Standards

- Validate all external input using the existing schema utilities.
- Authenticate the request before accessing user data.
- Enforce authorization at the resource level.
- Follow the error response structure used in @app/api/projects/route.ts.
- Do not expose internal errors or database identifiers.
- Add tests for success, invalid input, unauthenticated access, and forbidden access.
- Run the affected tests and type checking after changes.

AGENTS.md

AGENTS.md is a simpler Markdown-based option for repository-wide instructions.

It is useful when the project needs one readable document containing stable agent guidance without complex scoping.

# Project Instructions

## Product

This is a multi-tenant SaaS application for creating, optimizing, and organizing AI prompts.

## Stack

- Next.js
- TypeScript
- PostgreSQL
- Prisma
- Tailwind CSS
- Vitest
- Playwright

## Architecture

- Keep route handlers thin.
- Place reusable business logic in service modules.
- Validate all external input.
- Enforce user or workspace ownership on the server.
- Reuse existing UI components before creating new ones.

## Constraints

- Do not replace the authentication provider.
- Do not edit generated files manually.
- Do not change public API response formats without approval.
- Do not add dependencies without explaining the need.
- Do not run destructive database commands.

## Verification

Before reporting completion:

1. Run affected tests.
2. Run type checking.
3. Run linting.
4. Run the production build when relevant.
5. Report any validation that could not be completed.

What Should Not Become a Rule?

Avoid adding:

• Temporary feature requirements.
• Instructions that apply to only one task.
• Entire style guides already enforced by tools.
• Large copied code examples that can become outdated.
• Rare edge cases that add noise to every request.
• Vague statements such as “always write high-quality code.”

Rules should capture stable patterns that Cursor repeatedly needs to follow.

Reusable Cursor Commands

Repeated multi-step workflows can be saved as commands inside:

.cursor/commands/

A command can package a workflow such as:

• Reviewing the current diff.
• Preparing a pull request.
• Fixing a GitHub issue.
• Running release validation.
• Updating dependencies safely.
• Generating project documentation.

Example .cursor/commands/prepare-pr.md:

Prepare the current branch for a pull request.

1. Inspect staged and unstaged changes.
2. Compare the branch with main.
3. Identify unrelated modifications.
4. Run the relevant tests.
5. Run type checking and linting.
6. Stop if required validation fails.
7. Summarize the user-visible and technical changes.
8. Identify migration, configuration, or deployment requirements.
9. Suggest a concise commit message.
10. Draft the pull request title and description.

Do not push or open the pull request until I approve the summary.

Commands are most useful after you have already developed a repeatable workflow. Avoid creating commands for processes that are still changing frequently.

Cursor CLI Prompts

Cursor CLI allows the same general prompting workflow to be used from the terminal.

It can be useful for:

• Interactive coding sessions.
• Repository exploration.
• Reviewing changes.
• Resuming prior sessions.
• Structured output for scripts.
• CI and automation workflows.

Useful CLI prompting principles remain the same:

• State whether files may be modified.
• Define the exact repository scope.
• Specify required validation.
• Use structured output when another tool will process the result.
• Be cautious with automatic command and file permissions.

Example read-only review:

agent -p "Review the current changes without modifying files. Return findings grouped by severity with file locations, evidence, impact, and recommended verification." --output-format text

Example structured output:

agent -p "Analyze the current branch for security and backward-compatibility risks. Do not modify files." --output-format json

For autonomous or scripted file modifications, review the permission and safety implications before enabling write access or automatic command execution.

Weak vs. Strong Cursor Prompts

Weak Cursor Prompt

Add subscription billing to the app.

This prompt does not explain:

• Which billing provider should be used.
• Which plans exist.
• Which existing files and patterns matter.
• How plan access should be enforced.
• Which webhook events should be handled.
• What happens after cancellation or failed payment.
• What should remain unchanged.
• How the implementation should be tested.

Strong Cursor Prompt

Plan the addition of subscription billing to this existing SaaS application.

Do not modify files yet.

Product behavior:

- Free users receive 20 monthly usages.
- Pro users receive 1,000 monthly usages.
- Max users receive 5,000 monthly usages.
- Users can upgrade from the pricing page.
- Users can manage an active subscription from account settings.
- Access changes after a confirmed webhook event, not only after a client redirect.

Technical context:

- This is an existing Next.js and TypeScript application.
- Inspect the current authentication, user model, usage tracking, account settings, and pricing page.
- Locate existing service, validation, API response, and error-handling patterns.
- Use the existing payment provider integration if one already exists.

Required behavior:

- Create or update the checkout flow.
- Store provider customer and subscription identifiers safely.
- Process required subscription lifecycle webhooks.
- Make webhook processing idempotent.
- Enforce plan limits on the server.
- Handle upgrades, cancellations, failed payments, and expired subscriptions.
- Preserve existing users and usage records.
- Do not expose secrets or raw provider errors.

Constraints:

- Do not replace the authentication provider.
- Do not redesign unrelated account pages.
- Do not grant access based only on client-provided values.
- Do not execute destructive migrations.
- Do not add a dependency unless the existing stack cannot support the requirement.

Acceptance criteria:

- An authenticated user can start checkout for the selected plan.
- A confirmed webhook updates the correct account.
- Duplicate webhook delivery does not duplicate state changes.
- Canceled or expired subscriptions lose paid access according to the defined policy.
- Unauthorized users cannot modify another account.
- Existing free users continue to work.
- Relevant tests, type checking, linting, and build validation pass.

Before implementation:

1. Explain the current billing-related architecture.
2. List relevant files and symbols.
3. Identify missing product decisions.
4. Identify security and migration risks.
5. Propose a milestone-based implementation plan.
6. Wait for approval.

The strong prompt gives Cursor enough information to research the existing implementation and expose unanswered decisions before making broad changes.

A Reliable Cursor Workflow

Step 1: Explore

Do not modify files. Explain how the current workflow is implemented and identify the relevant files, symbols, dependencies, and tests.

Step 2: Clarify

List the requirements that are still unclear. Separate questions that block implementation from optional product decisions.

Step 3: Plan

Create a detailed implementation plan with affected files, data changes, compatibility concerns, acceptance criteria, and validation steps. Wait for approval.

Step 4: Implement

Implement only the approved scope. Follow existing patterns, preserve unrelated behavior, and add relevant tests.

Step 5: Verify

Run the required tests, type checking, linting, and build. Confirm every acceptance criterion and investigate failures.

Step 6: Review

Review the final diff for correctness, security, accidental changes, missing states, compatibility risks, and missing tests.

Step 7: Document

Summarize the implemented behavior, important decisions, modified files, validation results, limitations, and follow-up work.

Step 8: Reuse

If you repeatedly give Cursor the same instruction, move it into:

• A Project Rule for persistent scoped guidance.
• AGENTS.md for simple repository-wide guidance.
• A reusable command for repeated multi-step workflows.

Common Cursor Prompting Mistakes

Asking for Implementation Before Exploration

Cursor may select the wrong files or duplicate functionality that already exists.

Better approach: Ask for a read-only explanation and plan first.

Attaching Too Much Context

Adding entire folders that are unrelated to the task can make the important code harder to identify.

Better approach: Attach exact context when known and let Cursor search when it is not.

Combining Several Unrelated Tasks

A prompt that requests authentication, billing, dashboard redesign, analytics, and deployment at the same time is difficult to review.

Better approach: Divide the work into logical, independently verifiable tasks.

Leaving Existing Behavior Undefined

Cursor may unintentionally change APIs, data structures, or interface behavior.

Better approach: List what must remain unchanged.

Using Vague Acceptance Criteria

“Make sure it works” does not give the agent a reliable completion signal.

Better approach: Define user-visible outcomes and required validation commands.

Continuing One Conversation Across Unrelated Features

Long conversations can accumulate irrelevant context and previous assumptions.

Better approach: Start a new conversation for a new logical task and reference relevant past chats.

Turning Every Instruction Into a Rule

Large or overly general rules can add noise to every request.

Better approach: Store only stable, repeated, and actionable project guidance.

Trusting Generated Code Without Reviewing the Diff

Code may compile while still containing incorrect authorization, incomplete states, or unintended changes.

Better approach: Review the diff, run validation, and inspect security-sensitive behavior before merging.

Using PrompTessor for Cursor Prompts

A Cursor task often begins as a short instruction:

Add team invitations to my app.

That instruction communicates the general idea but does not define the current architecture, invitation workflow, permissions, expiration behavior, acceptance criteria, or testing requirements.

PrompTessor can help turn rough coding instructions into clearer prompts before they are sent to Cursor.

A practical workflow is:

1. Start with the feature, bug, or codebase question.
2. Add the relevant product outcome.
3. Explain the existing technical environment.
4. Define current and expected behavior.
5. Add scope, constraints, and non-goals.
6. Define acceptance criteria and validation commands.
7. Analyze the prompt for missing context.
8. Optimize unclear or ambiguous instructions.
9. Refine the prompt based on Cursor's clarification questions.
10. Save reusable prompts for planning, implementation, review, and verification.

The final prompt does not need to include every detail in the repository.

It should include the decisions Cursor cannot safely discover from the codebase alone.

Cursor Prompt Checklist

Before sending a complex task to Cursor, check whether the prompt explains:

• Whether Cursor should explore, plan, implement, or review.
• The specific technical or product outcome.
• The current behavior.
• The expected behavior.
• Known relevant files, symbols, or modules.
• Which existing patterns should be reused.
• Which behavior must remain unchanged.
• The functional requirements.
• The scope and non-goals.
• Technical and compatibility constraints.
• Authentication and authorization requirements.
• Migration or stored-data concerns.
• Observable acceptance criteria.
• Required tests and validation commands.
• How Cursor should report its work.

If several items are missing, begin with exploration and planning instead of immediate implementation.

Official Cursor Resources

• Cursor Agent Best Practices
• Cursor Agent Modes
• Cursor Context and @ Symbols
• Cursor Rules and AGENTS.md
• Cursor Agent Tools
• Cursor CLI Overview
• Using Cursor CLI

FAQ About Cursor Prompts

What are Cursor prompts?

Cursor prompts are natural-language instructions used to guide Cursor's AI features through understanding, planning, creating, modifying, testing, or reviewing code inside a development project.

What makes a good Cursor prompt?

A good Cursor prompt defines the task, expected behavior, relevant codebase context, scope, constraints, acceptance criteria, and verification requirements.

Should I use Ask Mode or Agent Mode?

Use Ask Mode for read-only exploration, codebase understanding, and technical questions. Use Agent Mode when the task is clear enough for Cursor to edit files, run commands, and complete a multi-step implementation.

Should Cursor plan before writing code?

For complex or multi-file tasks, yes. Planning helps expose missing requirements, locate existing patterns, identify risks, and create a reviewable implementation path before files are changed.

Do I need to reference every relevant file?

No. Cursor can search the codebase for relevant context. Reference exact files, folders, or symbols when they are known and important, but avoid attaching unrelated context.

What is the difference between Cursor Rules and AGENTS.md?

Cursor Project Rules support structured and scoped instructions inside .cursor/rules. AGENTS.md provides a simpler Markdown-based option for repository-wide instructions.

How long should a Cursor prompt be?

A Cursor prompt should contain the information required for the task. Small edits may need only a few sentences, while changes involving several modules, permissions, migrations, and compatibility require more detail.

Can Cursor build a complete application?

Cursor can help plan and implement substantial parts of an application. However, product decisions, security review, validation, deployment preparation, and maintenance still require careful human oversight.

How should I review code generated by Cursor?

Inspect the final diff, compare it with the approved requirements, run relevant validation, review security-sensitive boundaries, and verify important user workflows before merging.

Can Cursor prompts be used from the terminal?

Yes. Cursor CLI supports interactive and non-interactive prompting for code exploration, modification, review, and automation workflows.

Conclusion

Cursor becomes more useful when it is treated as a codebase-aware development agent rather than a simple code generator.

The best results come from giving it a structured task and a reliable process:

1. Explore the current implementation.
2. Clarify the desired outcome.
3. Create a reviewable plan.
4. Implement a controlled scope.
5. Run objective validation.
6. Review the final diff.
7. Store repeated guidance in rules or commands.

A strong Cursor prompt does not need to describe every line of code.

It needs to define the product behavior, technical boundaries, and evidence that determine whether the task was completed correctly.

That gives Cursor enough freedom to search and implement while keeping the developer in control of what changes and what ultimately ships.