Tools

Cursor and AI Code Editor Prompting

Get more out of Cursor and AI code editors: .cursorrules setup, effective context management, multi-file editing, codebase-aware prompting, and patterns for different development tasks.

Cursor and AI Code Editor Prompting

Cursor and similar AI code editors (Windsurf, GitHub Copilot, Zed AI) are transforming how developers write code. But most developers use them like autocomplete on steroids — accepting or rejecting suggestions without thoughtfully directing the AI. This guide covers how to use Cursor's features intentionally to get dramatically better results.

Understanding the Context Window

Cursor's AI features work by sending your code — plus your instruction — to a language model. The quality of results depends heavily on what context is included.

Cursor includes context from:

  1. The file you're currently editing
  2. Files you explicitly reference with @filename
  3. Files the model determines are relevant (Cursor's automatic context)
  4. Your .cursorrules file (project-wide instructions)

The key insight: the AI can only work with what it can see. If it's making incorrect assumptions, the fix is usually to add the relevant context.

.cursorrules: Your Project-Wide System Prompt

The .cursorrules file in your project root is sent as a system prompt for every AI interaction in that project. This is the highest-leverage thing you can configure.

What to Put in .cursorrules

# Project: fireflare
# Rust Axum web server — micro-social network for sharing AI prompts

## Tech Stack
- Rust (2021 edition), Axum 0.8, SQLx 0.8, PostgreSQL
- Askama 0.12 for server-rendered HTML templates
- HTMX for frontend interactivity
- ULID for all IDs (never UUID)

## Code Conventions
- Use `?` for error propagation — never `.unwrap()` in production paths
- All database queries must filter `WHERE deleted_at IS NULL` (soft deletes)
- Use `thiserror` for error enums
- Handlers follow this pattern: extract from request → call service layer → build template context → render
- Prefer `sqlx::query_as!` for compile-time query checking

## Testing Requirements
- Unit tests in `#[cfg(test)] mod tests` at the bottom of each file
- Database tests use `#[sqlx::test]`
- Test error paths, not just happy paths

## What Not to Do
- Do not use `.unwrap()` or `.expect()` in non-test code
- Do not use UUID — only ULID
- Do not add Redis dependencies (deferred to post-MVP)
- Do not use `offset`-based pagination — use cursor-based

A good .cursorrules eliminates the most common mistakes and makes every interaction project-aware.

The @ Context System

In Cursor's chat (Cmd+L or Ctrl+L), use @ to explicitly add context:

  • @filename.rs — include a specific file
  • @folder/ — include all files in a folder
  • @web — search the web for current information
  • @docs — search indexed documentation
  • @codebase — semantic search across entire codebase
  • @git — recent git diffs or commits

Effective Context Strategies

For implementing a new feature:

@routes/prompts.rs @models/prompt.rs @db/prompt_repo.rs

Add a new endpoint: GET /api/prompts/:id/forks
Returns a paginated list of forks for a given prompt.
Follow the same patterns as the existing list endpoint above.

For debugging:

@src/auth/middleware.rs @src/errors.rs

This middleware is returning 401 for valid sessions. Here's the error log:
[paste log]
Identify the cause.

For refactoring:

@codebase

Find all places where we're using offset-based pagination and replace
with cursor-based pagination. Show me the files first before making changes.

Inline Editing vs. Chat

Cursor has two main modes:

Inline Edit (Cmd+K)

Best for:

  • Making targeted changes to a selected block of code
  • Quick transformations ("convert this to async", "add error handling")
  • Generating a specific function you've selected the location for
# Select the function, then Cmd+K:
"Add input validation: title must be 1-200 chars, body 1-10000 chars"
"Convert to use the ? operator instead of match blocks"
"Add tracing::instrument with fields for user_id and prompt_id"

Chat (Cmd+L)

Best for:

  • Understanding code ("what does this function do?")
  • Planning before implementing ("what's the best approach for X?")
  • Multi-file changes
  • Generating tests
  • Code review

Multi-File Editing

Cursor's Composer (Cmd+I) can edit multiple files simultaneously. Use it for:

  • Adding a new feature end-to-end (route + handler + service + test)
  • Refactoring a pattern across many files
  • Database migration + updated queries + updated tests

Effective Composer Prompts

Be explicit about what files should change and what should stay the same:

Add a "view count" feature to prompts:
1. Add a migration: new column `view_count INT DEFAULT 0` on prompts table
2. Update the prompt repository to increment view_count on fetch
3. Add view_count to the prompt detail template context
4. Do NOT change the API response format or any existing tests

Patterns for Specific Tasks

Generating a New Endpoint

Using @routes/prompts.rs as a reference for the handler pattern,
add a new endpoint: POST /prompts/:id/like

Requirements:
- Requires authentication (use AuthUser extractor)
- Idempotent: liking twice should not create a duplicate
- Returns the new like count as JSON
- Add the route to @routes/mod.rs

Writing Tests

@src/db/user_repo.rs

Write integration tests for all functions in this file using #[sqlx::test].
Cover:
- create_user: success, duplicate email, duplicate username
- get_user_by_id: found, not found, soft-deleted (should not return)
- update_user: success, not found

Code Review

Review @src/auth/handlers.rs for:
1. Security: SQL injection, timing attacks on password comparison, session fixation
2. Error handling: are all errors handled explicitly?
3. Missing test coverage: what cases aren't tested?
Don't make changes — just report findings with line numbers.

Managing Long Sessions

AI code editor quality degrades in very long sessions as context accumulates:

  • Start fresh chat sessions for each distinct task
  • Use Composer for multi-file tasks (it manages context better)
  • After a big refactor, start a new session — old context about the pre-refactor code causes confusion

Key Takeaways

  • .cursorrules is the most important setup step — configure it before writing code
  • Explicit @context always beats relying on automatic context detection
  • Use inline edit (Cmd+K) for targeted changes, chat (Cmd+L) for planning and review
  • Composer handles multi-file changes — give it explicit instructions about what to change and what to leave alone
  • Start fresh sessions between distinct tasks to avoid context contamination
All Guides