• Format: Both tools use plain text or Markdown syntax. Rules should be clear, concise, and structured with headings, lists, or code blocks for readability.
• Content: Include project context, coding standards, preferred tools/libraries, and specific instructions. Use natural language or pseudo-code when needed.
• Comments: Use # or // for comments to explain intent (optional but helpful).
• File References: In Cursor, you can use @file to reference other files; Windsurf doesn't natively support this but can infer context from mentioned files.

• Cursor Rules:
  • File Name: .cursorrules (single file) or multiple .mdc files in a .cursor/rules directory (introduced in v0.45).
  • Location: Place .cursorrules in your project's root directory (e.g., /my-project/.cursorrules). For the newer system, create a .cursor/rules folder in the root and add .mdc files like react-rules.mdc.
  • Saving: Use any text editor (e.g., VS Code, Notepad) and save as plain text with the correct extension.
• Windsurf Rules:
  • File Name: .windsurfrules
  • Location: Save in your project's root directory (e.g., /my-project/.windsurfrules).
  • Saving: Same as Cursor—use a text editor and save as plain text.

Well-Written Cursor Rule (.cursorrules)

# Project: Task Tracker
## Context
- Building a React app with TypeScript, Tailwind CSS, and Next.js App Router.
- Focus on reusable components and minimal state.

## Guidelines
1. Use functional components with TypeScript interfaces for props.
2. Prefer Tailwind CSS for styling over CSS modules.
3. Avoid `useEffect` unless strictly necessary; use server components where possible.
4. Write concise, readable code with clear variable names.

## Example Component Structure
```tsx
interface ButtonProps {
  label: string;
  onClick: () => void;
}

export const Button = ({ label, onClick }: ButtonProps) => (
  <button className="px-4 py-2 bg-blue-500 text-white rounded" onClick={onClick}>
    {label}
  </button>
);
```

Why it's good: Specific, structured, includes context, guidelines, and an example. Cursor can reliably follow this to generate consistent code.

Well-Written Windsurf Rule (.windsurfrules)

**Project: API Client**

**Context**
* Node.js backend with Express and TypeScript.
* Uses npm, not pnpm or yarn.

**Rules**
* Always use async/await for promises, no .then().
* Structure endpoints in routes/ folder (e.g., routes/users.ts).
* Validate inputs with Zod before processing.

**Sample Route**
```ts
import { Router } from 'express';
import { z } from 'zod';

const router = Router();
const userSchema = z.object({ name: z.string(), age: z.number() });

router.post('/users', async (req, res) => {
  const data = userSchema.parse(req.body);
  res.json({ message: 'User created', data });
});
```

Why it's good: Clear project context, actionable rules, and a practical example. Windsurf's Cascade can use this to generate or edit code accurately.

• Be Specific: Define languages, frameworks, and patterns explicitly.
• Test Rules: After saving, ask the AI a simple task (e.g., "Write a button component") to ensure it follows your rules.
• Update as Needed: Refine rules as your project evolves.
• Leverage Structure: Use headings and examples to make rules easy for both you and the AI to interpret.

Prompts for Cursor and Windsurf should be written in plain English (or your preferred language), but they must be specific and structured to avoid ambiguity. Here's how to do it:

• Be Specific: Clearly define the task using action words like "generate," "refactor," "debug," or "explain." Vague requests lead to vague results.
• Provide Context: Mention the programming language, frameworks, or files involved to give the AI a clear scope.
• Use References: Both tools support referencing files or the codebase with syntax like @filename or @codebase to enhance context.
• Syntax: There's no strict format, but concise, logical sentences work best. For complex tasks, break them into steps (e.g., "First, create a file... Then, define a function...").

Tips

• Avoid jargon unless it's relevant to your codebase.
• If the AI's response isn't ideal, refine your prompt (e.g., "Fix the syntax error in the previous output").

You can save prompts in two ways, depending on their purpose:

• Project-Wide Instructions:
  • Cursor: Store them in the .cursor/rules/ directory within your project, typically in a file like .cursor/rules/cursorrules.mdc. Use Markdown or plain text (e.g., "Always use TypeScript").
  • Windsurf: Save them in a .windsurfrules file in the project root (e.g., "Prefer arrow functions over traditional functions").
• Task-Specific Prompts: These are usually written on the fly in the tool's interface (e.g., chat or inline edit features like Cursor's Composer or Windsurf's Cascade) and don't need saving unless you want to reuse them. For reuse, consider noting them in a personal file or using a text expansion tool like Espanso.

Where to Save

• .cursor/rules/ (Cursor) and .windsurfrules (Windsurf) live in your project directory.
• Check your tool's documentation for exact file naming or additional options.

Well-Written Prompts

• Prompt: "Generate a React component in @components/Login.js with a form for email and password, styled with Tailwind CSS."
  • Why it works: Specifies the task, file, and styling framework.
• Prompt: "Debug this JavaScript function in @sort.js; it should sort an array but fails with negative numbers."
  • Why it works: Provides context and identifies the issue.
• Prompt: "Refactor this Python code to use async/await instead of promises."
  • Why it works: Clear action and desired outcome.

Poorly Written Prompts

• Prompt: "Make a login page."
  • Why it fails: Lacks details on framework, structure, or location.
• Prompt: "Fix this."
  • Why it fails: No context or indication of what's wrong.
• Prompt: "Write some code."
  • Why it fails: Too vague; the AI can't guess your intent.