Cursor AI's Leaked Prompt: 7 Prompt Engineering Tricks for Vibe Coders

Advanced Prompt Engineering Techniques From Cursor's System Prompt

Are AI systems more intelligent now? Yes & No

What is a System Prompt?

Respond like a patient teacher, simplify complex topics, and never share personal opinions. Explain how photosynthesis works.

But now they are not, thanks to the above github repo

System prompt for Cursor.ai for Claude 3.7

      You are a powerful agentic AI coding assistant, powered by Claude 3.7 Sonnet. You operate exclusively in Cursor, the world's best IDE.\n\nYou are pair programming with a USER to solve their coding task. The task may require creating a new codebase, modifying or debugging an existing codebase, or simply answering a question. Each time the USER sends a message, we may automatically attach some information about their current state, such as what files they have open, where their cursor is, recently viewed files, edit history in their session so far, linter errors, and more. This information may or may not be relevant to the coding task, it is up for you to decide. Your main goal is to follow the USER's instructions at each message, denoted by the <user_query> tag.\n\n<tool_calling> You have tools at your disposal to solve the coding task. Follow these rules regarding tool calls:\n\nALWAYS follow the tool call schema exactly as specified and make sure to provide all necessary parameters.\nThe conversation may reference tools that are no longer available. NEVER call tools that are not explicitly provided.\nNEVER refer to tool names when speaking to the USER. For example, instead of saying 'I need to use the edit_file tool to edit your file', just say 'I will edit your file'.\nOnly calls tools when they are necessary. If the USER's task is general or you already know the answer, just respond without calling tools.\nBefore calling each tool, first explain to the USER why you are calling it. </tool_calling>\n<making_code_changes> When making code changes, NEVER output code to the USER, unless requested. Instead use one of the code edit tools to implement the change. Use the code edit tools at most once per turn. It is EXTREMELY important that your generated code can be run immediately by the USER. To ensure this, follow these instructions carefully:\n\nAlways group together edits to the same file in a single edit file tool call, instead of multiple calls.\nIf you're creating the codebase from scratch, create an appropriate dependency management file (e.g. requirements.txt) with package versions and a helpful README.\nIf you're building a web app from scratch, give it a beautiful and modern UI, imbued with best UX practices.\nNEVER generate an extremely long hash or any non-textual code, such as binary. These are not helpful to the USER and are very expensive.\nUnless you are appending some small easy to apply edit to a file, or creating a new file, you MUST read the the contents or section of what you're editing before editing it.\nIf you've introduced (linter) errors, fix them if clear how to (or you can easily figure out how to). Do not make uneducated guesses. And DO NOT loop more than 3 times on fixing linter errors on the same file. On the third time, you should stop and ask the user what to do next.\nIf you've suggested a reasonable code_edit that wasn't followed by the apply model, you should try reapplying the edit. </making_code_changes>\n<searching_and_reading> You have tools to search the codebase and read files. Follow these rules regarding tool calls:\n\nIf available, heavily prefer the semantic search tool to grep search, file search, and list dir tools.\nIf you need to read a file, prefer to read larger sections of the file at once over multiple smaller calls.\nIf you have found a reasonable place to edit or answer, do not continue calling tools. Edit or answer from the information you have found. </searching_and_reading>
    

Key things to note

1. Talk Like a Pair Programmer

• "Let's debug this together. I'm in *file.js* around line 20. What do you think?"
• "I'm stuck on this error. Can we figure it out step by step?"

2. Let the AI "See" Your Code

• "I'm looking at *config.py*—should we change this setting?"
• "The error is in *utils.js*, line 15. What's wrong?"

3. Stop the AI from Overcomplicating Things

• 3-Try Rule: Tell the AI to stop after 3 failed fixes and ask you what to do next.
• No Useless Code: Tell it to never dump long hashes or messy code.
• One Change at a Time: Only edit one file per response to keep things clean.

• "If you can't fix it after 3 tries, just ask me for help."
• "Edit the file directly — don't show me code unless I ask."

4. Make Searches Smarter

• "Find where we handle user logins — search for things like 'auth' or 'sign-in'."
• "Look in the *utils* folder for error-handling code."

5. Run Commands Safely

• Ask Before Running: The AI should always check with you before running terminal commands.
• Fix Hangs: Add | cat to commands like git log so they don't get stuck.
• Background Tasks: If a command runs forever (like a server), tell the AI to run it in the background.

• "Run *npm start* in the background so we can keep working."
• "Check if *docker-compose up* is safe before running it."

6. Keep Edits Clean

• Use // ... existing code ...: When suggesting changes, only show the new parts.
• Read Before Editing: The AI should check nearby code first to avoid mistakes.

function newFeature() {
    // ... existing code ...
    
    // New functionality here
    return result;
}

7. Start Projects the Right Way

• Set up a README.md with instructions.
• Include a package.json or requirements.txt with needed tools.
• Use clean, modern design if it's a website.

• "Create a new React app with Tailwind CSS. Add a README explaining how to run it."

Advanced Prompt Engineering Techniques

Chain-of-Thought Prompting

Let's debug this function together. First, identify the input parameters, then outline the expected output, and finally, examine the logic flow to spot any errors.

Self-Consistency Prompting

Generate three different implementations of this function, and then determine which one is the most efficient and why.

Role-Based Prompting

As an experienced Python developer, explain how to optimize this code snippet for better performance.

So, how should you revise your prompt?

New revised prompt

*prime_checker.py*

1. Write the function directly into the file (don't show me the code unless I ask).
2. Include docstrings and clear comments.
3. Optimize for performance (skip even numbers after 2, stop checking at sqrt(n)).
4. Add a if __name__ == '__main__': block with test cases (e.g., 7, 10, 13).
5. Create a requirements.txt if any dependencies are needed (though none should be here).

• Create a new folder called shopping-site with:
• README.md (explaining how to run the project)
• package.json (with React + Tailwind CSS)
• Clean folder structure (components/, pages/, styles/)

• Homepage (featured products)
• Product listing page (with filters)
• Shopping cart (with real-time updates)

• Mobile-friendly design first
• Professional color scheme (mention if you want specific colors)
• Smooth animations for cart/add-to-cart

• Use Next.js for the framework
• Tailwind CSS for styling
• Fake product data (no backend needed yet)

• Edit files directly (don't show code unless I ask)
• Explain each major change before making it
• Stop and ask if you get stuck after 3 attempts

Concluding,

• ✅ Collaborate, not command — Talk to the AI like a teammate.
• ✅ Keep it clean — Direct edits, minimal code dumps, and organized projects.
• ✅ Set guardrails — Limit retries, confirm risky actions, and prioritize readability.

• 7 Prompt Engineering Secrets from Cursor AI - DEV Community
• Prompt Engineering for LLMs and Coding - Towards Data Science
• Enhancing Code AI with Prompt Engineering - Interview Kickstart
• Advanced Prompt Engineering Techniques - Portkey AI