Cursor AI Tips & Setup Guide

Generate a .cursorrules file for my project:

Tech stack: {{tech_stack}}
Framework: {{framework}} (version {{version}})
Language: {{language}}
Testing: {{test_framework}}
Styling: {{styling_approach}}

The rules file should include:
1. Project context (stack, structure, key directories)
2. Code style rules (naming, imports, file organization)
3. Framework-specific patterns (e.g., prefer server components, use App Router)
4. Error handling conventions
5. What NOT to do (common anti-patterns for this stack)

Keep it under 50 lines. Every rule should be specific and actionable — no generic advice like "write clean code".

I need to implement {{feature_name}}.

Here's the plan — execute each step in order:

Step 1: Create the data model / types in {{types_location}}
Step 2: Build the API route at {{api_path}} with GET and POST handlers
Step 3: Create the UI component at {{component_path}}
Step 4: Wire up the component to the API with proper loading/error states
Step 5: Add form validation using {{validation_library}}

For each step:
- Follow existing patterns in the codebase (check similar files first)
- Use @{{reference_file}} as a reference for style and structure
- Do NOT modify any files outside the ones listed above

After all steps, list any environment variables or dependencies I need to add.

Refactor this {{code_element}} to:
1. {{primary_change}}
2. Keep the existing public API / function signature unchanged
3. Add proper TypeScript types (no `any`)
4. Handle the error case where {{error_scenario}}
5. Add a JSDoc comment explaining the purpose and parameters

Constraints:
- Do not rename the export
- Do not change how this is called from other files
- If you need a helper function, define it in the same file as a non-exported function

I need to understand how {{feature_or_concept}} works in this codebase.

Search the project and answer:
1. Which files implement this feature? List them with their roles.
2. What's the data flow from user action to database and back?
3. Are there any shared utilities or hooks this feature depends on?
4. What are the current limitations or TODOs related to this?
5. If I wanted to {{proposed_change}}, which files would I need to modify?

Reference specific file paths and function names in your answer. Use @-mentions for the key files so I can navigate to them.

Refactor {{pattern_to_change}} to {{new_pattern}} across the codebase.

Scope: Only files in {{directory}}
Pattern to find: {{old_pattern_description}}
Replace with: {{new_pattern_description}}

Rules:
- Update all imports that reference changed exports
- Update any tests that test the changed code
- Do NOT change the behavior — this is a pure refactor
- If a file uses the pattern but changing it would be risky, flag it with a comment instead of changing it
- After all changes, run the project's lint command and fix any issues

List every file you changed and what you changed in it.

Generate tests for @{{file_to_test}}.

Test framework: {{test_framework}}
Test file location: {{test_file_path}}

Requirements:
- Look at existing tests in the project first (check {{test_directory}}) and match their patterns
- Test the public exports only
- Include these categories:
  * Happy path (normal inputs, expected outputs)
  * Edge cases (empty, null, boundary values)
  * Error cases (invalid input, network failures, timeouts)
- Mock {{dependencies_to_mock}} using the project's existing mock patterns
- Each test name should describe the scenario: "should [expected behavior] when [condition]"

Do NOT test implementation details like private functions or internal state.

There's a bug: {{bug_description}}

Steps to reproduce:
1. {{step_1}}
2. {{step_2}}
3. {{step_3}}

Expected: {{expected_behavior}}
Actual: {{actual_behavior}}

Investigate by:
1. Read the relevant files starting from @{{entry_point}}
2. Trace the execution path that leads to this behavior
3. Identify the root cause (show me the exact line)
4. Propose the minimal fix
5. Check if the same bug pattern exists elsewhere in the codebase

Apply the fix only after I confirm. Show me the diff first.

Extract a reusable component from @{{source_file}}.

The section to extract: {{section_description}}

New component requirements:
- File path: {{new_component_path}}
- Props interface with full TypeScript types
- Accept a className prop for style overrides
- Use {{styling_approach}} for styling (match the project)
- Include default prop values where sensible
- Export both the component and its props type

After extraction:
1. Update the original file to use the new component
2. Ensure no visual or behavioral changes (pure refactor)
3. If the extracted section had local state, decide whether state should live in the new component or be passed as props — explain your choice