Cursor Rules Guide - Vibe Coding: Build Anything Using Simple English Prompts

This is the second part of the original post: "Vibe Coding: How to Build Anything Using Simple English Prompts."

In this post, you’ll find the Cursor Rules Guide, which outlines essential principles for clean, simple, and effective coding in the Cursor IDE.

1. Initial Setup (Cursor Settings)

In the Cursor IDE (or the tool you are using):

• Open Cursor.
• Navigate to Settings.
• Under Rules, paste the default rules listed below or in Cursor-Rules (Google Doc) . This will provide a baseline for users.
• Tick the option Include .cursorrules file.

This will allow you to load a separate .cursorrules file from your project directory for extra flexibility.

2. Directory Setup

In the directory where Cursor is opened:

• Create a file called .cursorrules.
• Add any additional or modified rules there.

This keeps default rules safe and clean, while still letting you customize project-specific rules.

3. Community Contributions : Suggest Your Own Rules (Google Doc)

• You can comment to suggest new rules or improvements.
• I will manually review and update them.
• Even if not updated immediately, everyone can view all comments.
• Important: Please do not delete or strike out others' comments. Let’s keep it transparent and collaborative!

Note: These are all my personal rules and are mostly inspired by David Ondrej. Feel free to remove, add, or modify them based on your needs!

Cursor Rules : Cursor-Rules (Google Doc)

# Fundamental Principles

• Write clean, simple, readable code.
• Implement features in the simplest possible way.
• Keep files small and focused.
• Test after every meaningful change.
• Focus on core functionality before optimization.
• Use clear, consistent naming.
• Think thoroughly before coding. Write 2–3 reasoning paragraphs.
• Always write simple, clean, and modular code.
• Use clear and easy-to-understand language. Write in short sentences.

# Error Fixing

• DO NOT JUMP TO CONCLUSIONS! Always consider multiple possible causes.
• Explain problems in plain English.
• Make minimal necessary changes.
• For strange errors, ask the user to perform a Perplexity web search.

# Building Process

• Verify each new feature works by telling the user how to test it.
• DO NOT write complicated and confusing code.
• Opt for simple and modular approaches.
• When unsure, tell the user to perform a web search.

# Comments

• ALWAYS add helpful and explanatory comments into the code.
• NEVER delete old comments unless obviously wrong or obsolete.
• Include LOTS of explanatory comments.
• Document all changes and their reasoning inside comments.
• When writing comments, use clear and easy-to-understand language. Write in short sentences.