Cursor

Good for: Write code with AI.

Prompts

Team and officeRun the business

Write a rules file so Cursor fits your project

What it does: Reads how your project is set up and writes a short Cursor rules file, so its changes match your code and don't touch what they shouldn't.

Use it when: Cursor keeps adding new libraries, renaming things, or editing files you didn't ask about.

You get: A rules file under 40 lines, where to save it, and 3 test asks to see if Cursor follows it.

Open in

See the prompt

You are my setup helper, inside my project in Cursor.

What the project is: [one line, for example: my business website]
What must never change: [for example: the payment page, the .env file]
How I like changes: [for example: small, one file at a time, explain first]

1. Look at the project: the language, the framework, how files are named, how it's tested, how it's run.
2. Write a rules file under 40 lines:
   - what the project is and what it uses
   - naming and file rules you can see in the code
   - never add a new library without asking
   - never touch the files I said must never change
   - my change rules, in my words
   - run the tests (or say there are none) after each change
3. Tell me where to save it in this project for Cursor to use it.
4. Give me 3 test asks to check Cursor follows the rules.

Rules:
- Only write rules you can see in the code or that I gave you.
- If you have to pick something I didn't give you (a name, a time, a setting, a day), mark it (suggested).
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.

Last, save these steps as a skill called 'Cursor Rules' so you do it this way each time I set up Cursor on a project.

Built from: The E-Myth Revisited, Michael E. Gerber, Chapter 8: The Franchise Prototype

You needCursorTested on sample data

Team and officeRun the business

Ask Cursor to fix one bug without breaking the rest

What it does: Writes a fix request that makes Cursor find the cause first, show you the plan, then change as little as it can.

Use it when: You asked for a small fix and got 12 changed files.

You get: A fix request for Cursor, the plan it should show you, and a check list before you accept the change.

Open in

See the prompt

You are my bug fix helper, inside my project in Cursor.

The bug: [what's wrong, in plain words]
How to make it happen: [steps]
What should happen: [expected]
Any error text: [paste]

Do this, in order, and stop after step 2 until I say go:
1. Find where the bug comes from. Show me the file and the lines, and why you think so.
2. Show me your fix plan: which files you'll change, what you'll change, and what you won't touch. Smallest change that fixes it.
3. After I say go, make only that change.
4. Tell me how to test it, step by step.
5. List anything else you noticed but didn't change.

Rules:
- No new libraries. No renaming. No style changes.
- If you're not sure of the cause, say so and tell me what to check.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.

Last, save these steps as a skill called 'Fix One Bug' so you do it this way each time I ask for a bug fix.

Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 7: Prioritize and Execute

You needCursorTested on sample data