Cursor vs Windsurf — AI Code Editors Compared

Refactor this function to improve readability and performance:

File: {{file_path}}
Function: {{function_name}}

Requirements:
- Break it into smaller functions if it exceeds 25 lines
- Extract magic numbers into named constants
- Replace nested if/else chains with early returns or a strategy pattern
- Preserve the exact same inputs and outputs (don't change the public API)
- Match the naming conventions used in the rest of {{file_path}}

Performance improvements:
- Replace any .find() inside a loop with a Map/Set lookup
- Memoize expensive computations if called multiple times with same args
- Remove unnecessary object spreads or array copies

After refactoring, show a before/after comparison of the most significant change and explain the performance improvement.

Implement the following feature:

Feature: {{feature_description}}
Acceptance criteria:
{{acceptance_criteria}}

Technical context:
- Framework: {{framework}}
- Relevant existing files: {{relevant_files}}
- Similar existing feature to reference: {{reference_feature}}

Implementation plan:
1. List all files that need to be created or modified
2. Implement the feature following the patterns in {{reference_feature}}
3. Write tests for every acceptance criterion
4. Update any shared types/interfaces affected by the change
5. Add/update API routes if the feature requires backend changes

Rules:
- Follow existing project conventions exactly (check the reference feature)
- No new dependencies without explaining why existing ones can't work
- Every user-facing string should be in the existing i18n pattern (if one exists)
- Handle loading, error, and empty states for any new UI components

Deliver as a list of files with their complete contents, ordered by dependency (types first, then backend, then frontend).

Answer this question about the codebase: {{question}}

To answer accurately:
1. Search for and read all relevant files — don't guess from file names alone
2. Trace the execution path from the entry point to the answer
3. If the answer involves multiple files, show the connection between them
4. Quote specific lines of code as evidence for your answer

Format your answer as:
**Short answer**: 1-2 sentence direct answer
**Detailed explanation**: The full trace with file references
**Files involved**: List of file paths, in order of relevance
**Related**: Note any related code that the developer might also want to know about

If you're not certain about something, say so and explain what additional files you'd need to check.

Create a {{component_name}} component matching this design spec:

Visual spec: {{design_description}}
Variants: {{variant_list}}
States: default, hover, active, disabled, loading, error

Technical requirements:
- Use {{styling_system}} (match the project's existing approach)
- Responsive breakpoints: mobile (320px), tablet (768px), desktop (1024px+)
- Support dark mode if the project uses it (check for existing dark: classes or theme tokens)
- Animate transitions with {{animation_library}} if the project uses one, otherwise CSS transitions
- Accessible: WCAG 2.1 AA — proper contrast ratios, focus rings, screen reader support

Component API:
- Props should mirror similar components in the project (check {{similar_component}} for patterns)
- Use forwardRef if the project's components do
- Export prop types for consumers

Deliver:
1. The component file
2. A Storybook story or usage example showing all variants and states
3. A brief list of design decisions you made and why

Audit and improve error handling in {{file_or_module_path}}.

Current state: {{current_error_handling}}

Audit checklist:
1. **Unhandled promises**: Find any async operations missing try/catch or .catch()
2. **Silent failures**: Find catch blocks that swallow errors without logging or rethrowing
3. **Generic catches**: Replace catch(e) with specific error type handling where appropriate
4. **User-facing errors**: Ensure errors shown to users are helpful, not stack traces
5. **API boundaries**: Verify all API calls handle network errors, timeouts, and unexpected response shapes
6. **Validation gaps**: Find inputs that aren't validated before use

For each issue, provide:
- Location (file:line or function name)
- Current code
- Fixed code
- Why this matters (what could go wrong in production)

Then add:
- A centralized error handler if the project doesn't have one
- Retry logic for transient failures (network, rate limits) with exponential backoff
- Error boundary components for React UI sections that could crash

Generate a REST API route for {{resource_name}} following this project's existing patterns.

Reference route: {{reference_route_path}} (use this as the style guide)
Framework: {{framework}}
ORM: {{orm}}
Auth: {{auth_method}}

Endpoints to create:
- GET /api/{{resource_name}} — list with pagination, filtering by {{filter_fields}}, sorting
- GET /api/{{resource_name}}/[id] — single resource with {{related_resources}} included
- POST /api/{{resource_name}} — create with Zod validation
- PATCH /api/{{resource_name}}/[id] — partial update
- DELETE /api/{{resource_name}}/[id] — soft delete if project uses it, hard delete otherwise

Each endpoint must include:
- Auth check (match the pattern in {{reference_route_path}})
- Input validation with descriptive error messages
- Proper HTTP status codes (201 for create, 204 for delete, 422 for validation errors)
- Rate limiting if the project has it
- Consistent response shape matching existing endpoints

Also generate:
- TypeScript types for request/response bodies
- A Zod schema for the create and update payloads
- An API client function that the frontend can use to call each endpoint

Audit {{file_or_component_path}} for performance issues.

Context: This is a {{component_type}} that {{what_it_does}}. Users report it feels {{performance_complaint}}.

Check for:

**React-specific** (if applicable):
- Unnecessary re-renders: missing memo, useMemo, useCallback
- State updates that could be batched
- Components that should be lazy-loaded
- Large lists missing virtualization

**Data fetching**:
- Waterfall requests that could be parallel
- Missing caching / stale-while-revalidate
- Over-fetching (fetching more data than displayed)
- N+1 query patterns

**Bundle**:
- Large imports that could be tree-shaken or dynamically imported
- Dependencies with smaller alternatives

**Runtime**:
- Expensive computations on every render
- DOM measurements forcing layout thrashing
- Animation jank (layout properties instead of transform/opacity)

For each issue:
- Impact: High / Medium / Low
- Current code snippet
- Optimized code snippet
- Estimated improvement (be specific: "reduces re-renders from N to 1" or "cuts bundle by ~40KB")

Prioritize by impact. Don't suggest micro-optimizations that save less than 1ms.

Analyze this project and write a {{rules_format}} file ({{file_name}}).

Scan the project and detect:
1. **Language & framework**: Versions, key dependencies
2. **Code style**: Indentation, quotes, semicolons, trailing commas (check .eslintrc, .prettierrc, or infer from code)
3. **Naming conventions**: Files (kebab-case, PascalCase?), functions, components, constants, types
4. **Import patterns**: Ordering, path aliases, barrel exports
5. **Component patterns**: Functional vs class, prop drilling vs context, state management library
6. **Testing patterns**: Framework, file naming (*.test.ts vs *.spec.ts), assertion style
7. **Project structure**: Where things live and the rationale

Write the rules file with:
- Project overview section
- Tech stack summary
- Specific do's and don'ts based on actual patterns found
- File structure guide
- Common commands (dev, build, test, lint, deploy)
- Example code snippets showing the "right way" for this project

Make every rule specific and evidence-based. Instead of "use descriptive names," say "use camelCase for functions, PascalCase for components, SCREAMING_SNAKE for constants" — based on what you actually found in the code.